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Introduction 


Division II 


Introduction 

Division II describes services to be provided by the Contractor in support of the 

Regional Fare Coordination System. The following provides a brief summary of each 

Section of Division II. 

Section 6.11-1 through 6.11-8 

These describe centralized services required to provide or support the following 

RFCS functions: 

• Customer Service. Each public transportation Agency will continue to 
provide direct customer service to their customer base. This section describes 
additional customer service functions to be provided on a regional level for 
the RFCS. 

• Institutional Programs. Institutional program customers form a primary 
market for public transportation Agencies in the Central Puget Sound Region. 
Innovative fare card issuance and revalue solutions are required for these 
customers, to maximize flexibility and convenience for the institutions, 
cardholders, and Agencies. 

• Card Procurement and Distribution. This describes RFCS functions related 
to the procurement and inventory of fare cards, and distribution to issuance 
points in the revalue network. 

• Card Management. This includes initializing, issuing and updating cards, 
tracking of all fare cards in circulation, and maintaining central system 
databases with relevant card account information. 

• Clearinghouse Services. This refers to the provision of central management, 
control and settlement functions required for the overall operation of the 
RFCS. 

• Financial Management. This describes the services required for the financial 
management of revenues accrued through the RFCS. 

• Network Management. The RFCS will include a number of central and 
distributed systems in a network. This section describes requirements for the 
overall management of that network. 


Section 6.11-9 

This describes requirements for the fare card revalue network. The Contractor shall 
provide the equipment, training and technical maintenance to support a retail revalue 
network. The Agencies will determine retail site locations, establish accounts with the 
retailers, and manage the accounts on a day to day basis. The Contractor is 
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encouraged to identify innovative revalue strategies and systems that provide regional 
revalue options, and meet the needs of all public transportation customer markets. 


Sections 6.11-10 through 6.11-12 

These describe services that the Contractor shall provide in support of the 

implementation and ongoing operation of the overall RFC system. These include: 

• Technical Support and Maintenance for equipment and systems installed as 
part of this Contract. 

• System Implementation criteria, to be used by the Contractor to develop an 
implementation plan. A phased implementation is anticipated, and close 
coordination will be required with each Agency to accommodate their specific 
needs and constraints. 

• Training. This includes training Agency staff and trainers in the installation, 
operation and maintenance of RFCS equipment. 



Customer Service 


Division II 


6.11- 1 Customer Service 

6.11- 1.1 Customer Service Description 

Customer service functions shall include call center, mail center, and Internet 
functions. For call and mail center functions, the Agencies shall provide “first tier” 
customer service for both individual cardholders and institutions (DR 1) as follows: 

• Providing call center functions in a “card not present” environment that 
includes establishing new individual and institutional accounts, issuing cards, 
providing RFCS program information (including alternative languages), 
responding to card account inquiries, updating card account parameters, and 
conducting basic troubleshooting. 

• Providing mail center functions and local fulfillment of individual card and 
batch institutional orders. Mail center functions shall include establishing 
new individual and institutional accounts, providing RFCS program 
information, issuing individual and batch card orders, responding to mail in 
card account inquiries, updating card account parameters, conducting basic 
troubleshooting, and replacing cards. 

• Providing fulfillment of individual card and batch institutional orders received 
through the Internet website. 

The Contractor shall provide the equipment and functionality to allow the agencies to 
provide first tier customer service functions, including on-line access to a knowledge 
base and help database. The Contractor shall also directly provide the following 
customer service functions: 

• Provision of “second tier” call functions in a “card not present” environment 
that includes all of the agency functions listed above, as well as advanced 
troubleshooting. All calls will initially be received by an agency, and 
forwarded for second tier support only if the local Agency is unable to resolve 
the problem. 

• Operation of an Internet website on behalf of the agencies to support 
individual card account establishment and management, and institutional 
account management (institutional account establishment will be the 
responsibility of the Agencies). Fulfillment of Internet orders will be by the 
Agencies. 

The Contractor provided customer service functions are envisioned as augmenting the 
Agency provided services, and will focus on service issues specific to the RFCS card. 
Calls or other queries received by the Contractor related to Agency specific issues, 
such as route or fare information, shall be routed to that Agency for disposition. 




Over the counter face to face customer service shall be provided at Agency CSO 
locations, and shall be supported electronically through the Contractor’s central 
systems. 

6.11-1.2 Functional Requirements 
1.2.1 Customer Service 

The Contractor shall provide the equipment and services to support first 
and second tier customer service activities as listed in Figure II-l.l. 

Figure II-l.l: Customer Service Activity Summary 
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* Revalues handled through the Call Centers, Mail Centers and Internet will be downloaded to the revalue 
network. 

** The Internet website will be operated by the Contractor on behalf of the Agencies. 

*** Fare Transactions should be available through a separate link on the primary customer page. 


1.2.2 Call Center 

(a) The Contractor shall provide the RFCS equipment and services 
required for the Agencies to perform first tier customer service 






























activities listed in Figure II-l.l (DR 1.01). All call center 
equipment and services shall be operable in a “card not present” 
environment. The Agencies will provide facilities, local 
communications, existing financial management systems, and 
existing telephone, call management and interactive voice response 
systems. 

(b) The Contractor shall provide the equipment and services to 
receive, queue and manage calls transferred from any Agency’s 
call center to the Contractor for second tier customer service. Calls 
may be transferred through: 

i. An Agency’s existing interactive voice response (IVR) or 
call management system or systems. 

ii. Manual transfer of calls by an Agency customer service 
representative. 

(c) The Contractor shall provide a toll free staffed call center service 
which is available Monday through Sunday between the hours of 
6 a.m. and 8 p.m. (Pacific Time) to accept calls and to perform 
second tier activities listed in Figure II-l.l. 

(d) Direct access to Contractor customer service and technical 
representatives shall be provided during staffed hours. Automated 
response technologies may be used during non-staffed hours, 
subject to approval by the Contract Administrator. 

(e) The call center shall have capabilities for transferring calls related 
to routing, fare, and other Agency specific issues to the relevant 
Agency for disposition. Automated response technologies shall 
include functions to transfer calls to specific Agencies. 

1.2.3 Mail Center 

(a) The contractor shall provide the equipment and services for a 
single agency, operating on behalf of the Agencies, to provide 
single card and batch mail center functions and fulfillment as 
indicated in Figure II-l.l (DR 1.01). 

1.2.4 Agency Customer Service 

The Contractor shall provide support services for Agency operated walk- 

in (CSO), telephone, and mail customer service facilities. A description of 

these services is contained in Section 6.II-5 “Clearinghouse Services.” 

1.2.5 Internet Website 


The Contractor shall describe their proposal for the establishment and 
operation of an Internet Website (DR 1.02) per the requirements listed 



below, indicating any variations, exceptions, additions or 
recommendations regarding the use of the Website for customer service. 

(a) The Contractor shall provide and operate an Internet Website on 
behalf of the Agencies. 

(b) The Website shall be designed for accessibility. Website 
publishing/accessibility guidelines will be provided by the 
Contract Administrator at Conceptual Design Review (DR 1.03). 
Additional information on web accessibility can be found at_ 
http://www.w3.org/WAI/. 

(c) The Contractor shall provide the equipment and services necessary 
for individual card and batch orders to be routed to and fulfilled by 
the Agency operating on behalf of the Agencies. 

(d) The Website shall be branded per the requirements of the 
Agencies, and shall be used solely for RFCS customer service (the 
site shall not be shared with non-RFCS agencies). 

(e) The Website shall be accessible through hotlinks on each Agency 
website, and shall include hotlinks back to each Agency website. 

(f) The Website shall provide the functions listed in Figure II-l.l. 

Only cards initialized as an “adult” shall be issued through the 
Website. All reduced fare cards shall only be issued through an 
Agency CSO or mail center. 

(g) The Website shall provide for Secure Electronic Transactions. 

(h) The Website shall maintain the privacy of all customer data and 
account parameters, allowing only authorized access. 

(i) The Contractor shall establish a separate Website page or pages to 
support institutional account management, and shall provide 
additional security to guard against unauthorized access. 

Authorized institutional account representatives shall be able to: 

i. Access card usage statistics for all cards sponsored by the 
institution. 

ii. Access subsidy utilization statistics (type of fare used for) 
for all cards sponsored by the institution. 

iii. Order and issue new cards. 

iv. Cancel cards (subject to RFCS policies). 

v. Update subsidy amounts. 

vi. Update cardholder personal information. 



(j) 

A designated agency shall act as the merchant of record for all 
Website card issuance and revalue functions. 

00 

Customers with linked cards and institutions shall be able to 
establish a personal identification number (PIN) or password for 
access to account information. 

(1) 

Customer and institutions shall be able to change a PIN or 
password through the Website. 

(m) 

The Website shall include secure provisions to provide customer or 
institutional access to an account if a PIN or password is forgotten 
or lost, and provide a new PIN or password. 

6.11-1.3 Performance Requirements 

1.3.1 Call Center 


Comprehensive, responsive and accurate customer service is important for 
the success of the RFCS initiative. 

(a) 

The Contractor shall identify any assumptions regarding the 
allocation of first tier and second tier call center services. 

(b) 

The Contractor shall identify quantifiable quality standards and the 
level of service to be provided to RFCS customers for second tier 
support, and shall identify methodologies for measurement (DR 
1.04). A minimum set of performance metrics for the call center 
operation is: 


i. Call center answer rates, number of rings 

ii. Number of calls 

iii. Number of calls answered and number dropped 

iv. Reason for call 

v. Average wait time 

vi. Customer satisfaction assessment 

vii. Accuracy of service (inquiry responded to correctly) 

(c) 

The Contractor shall provide regular (minimum monthly) 
measurement reports against the identified standards and level of 
service for second tier call center operation (CDRL 4). 

(d) 

The Contractor shall maintain a on-line knowledge database 
accessible for both first tier and second tier customer service, and 
shall update the database as new problems are detected and 
corrected (DR 1.05). 



(e) Customer service functions shall be completed in accordance with 
1.3.1.(b). The Contractor shall meet the following minimum call 
center service performance standards. 

i. Fare cards revalued on the next daily download cycle 
following the request. 

ii. Card, privilege, and application blocks completed on the 
next download cycle after receiving the request. 

iii. Value replacement on linked will be made in the following 
timeframes: 

1. Pass Value: Current pass value will be transferred to 
the replacement card, when the new card is issued 
to the cardholder, whether remotely or at a walk in 
center. 

2. Purse Value: Remaining purse value will be 
transferred to the new card, “x” days after the lost 
or stolen card report is made. This time period will 
allow potential late purse transactions to arrive at 
the central clearinghouse for processing, and 
accurate calculation of the actual purse balance. 

1.3.2 Internet Website 

(a) The Internet Website shall provide on-line access to card and 
account information, subject to security provisions. 

(b) The Contractor shall identify quantifiable quality standards for 
Internet Website operation (DR 1.06). 

(c) The Contractor shall provide regular (minimum monthly) 
measurement reports against the identified standards (CDRL 4). 

6.11-1.4 New Card Fulfillment (Option) 

The Contractor shall propose an option to provide additional card fulfillment 
functions as follows: 

(a) The Agencies will be responsible for: 

i. Fulfilling single card or small batch (<100 cards) over the counter orders. 

ii. Fulfilling single card or small batch (<100 cards) telephone and mail 
orders received directly by an Agency. 

iii. Establishing institutional program agreements and accounts. 

(b) The Contractor shall be responsible for: 

i. Fulfilling single card orders received through the Internet website or by 
mail. 



ii. Fulfilling initial institutional account orders placed by an Agency on 
behalf of an institution. 

iii. Fulfilling large batch (>100 cards) orders place by an Agency, whether for 
that Agency or on behalf of a customer. 

iv. Fulfilling institutional account re-orders received through the Internet 
website or by mail. 

(c) For orders fulfilled by the Contractor, the Contractor shall provide all card 
initialization, personalization and linking. The Contractor shall also set up 
institutional account parameters on cards distributed to institutions, subject to 
the agreement between the Agency and institution. 

(d) The Contractor shall accept all forms of payment for mail order card orders 
including cash, check, credit card, debit card, direct bank debit, and purchase 
order. The Contractor may accept reduced payment options through the 
Internet website. 

(e) For credit card and debit card sales, a designated Agency will act as merchant 
of record. The Contractor shall act on behalf of that Agency. 

(f) The Contractor shall be liable for non-payment of funds, except for 
Institutional Account payments governed by an agreement between an 
Agency and Institution. 

(g) The Contractor shall adhere to cash management practices per the 
requirements of the Washington Office of the State Treasurer and Office of 
Financial Management. 

(h) The Contractor shall deliver FOB destination single card orders within forty- 
eight (48) hours, small batch orders within seven (7) days, and large batch 
orders within fourteen (14) days. 

(i) All proposed fees shall be subject to approval by the Contract Administrator. 
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6.U-2 Institutional Programs 

The term Institutional Program refers to arrangements between an Agency and an 
employment, educational, commercial or human service institution which provides 
for designated travel privileges for the employees/students/faculty/staff/clients of that 
institution on the transportation services of the Agency Institutional programs and 
arrangements vary by Agency A summary of the approximate number of institutional 
programs and annual fare media/dollar volumes is contained in Figure II-2.2 at the 
end of this section. 

Under the RFCS, the Agencies will manage the Institutional Program and will 
continue as the primary contact for program participants, with responsibility for 
soliciting and managing institutional accounts. The Contractor shall be responsible 
for providing Institutional Program administrative support services on behalf of the 
Agencies including: 

• Customer Service (per Section 6.II-1). 

• Fare Card Management (per Section 6.II-4). 

• Clearinghouse Services (per Section 6.II-5). 

• Financial Management (per Section 6.II-7). 

• Network Management (per Section 6.II-8). 

Procedures for resolving payment disputes will be defined in the individual account 
agreements between the Agencies and the institution. The Agencies will bear the risk 
of loss in the event of non-payment by the institution. 

Four overall Institutional Programs will be included in the RFCS: 

• Employer. 

• Commercial Account (WSF). 

• Campus. 

• Human Service. 

These programs have core common functional requirements, as well as program- 
specific requirements. The Contractor shall support the full range of requirements for 
each program within the RFCS. 

For all institutional programs, the system shall support pre- or post-billing options 
based on monthly, 3-month, semi-annual, or annual billing periods, as well as 
combinations of these alternatives. The billing period may not be the same as the pass 
period - e.g. an institution may purchase annual passes, but may have the cost of those 




passes billed on a monthly basis for the number of passes in use. The system shall 
generate billing information for subsequent invoicing by a designated Agency or 
Agencies. Invoicing of the institution and collection of accounts receivable will be 
done by a designated Agency. 

6.11-2.1 Institutional Program Descriptions 
2.1.1 Employer Programs 

Employer programs involve a financial subsidy by employers for travel on 
one or more Agency services by their employees. Three (3) different 
employer programs shall be provided by the Contractor in the RFCS, 
corresponding to existing employer program types as summarized in 
Figure II-2.1. 


Figure 11-2.1: RFCS Employer Programs 


New RFCS Employer Program Type 

Existing Employer Program Type 

1. Right-to-Ride 

• FlexPass 

2. Electronic Voucher 

• Commuter Bonus Voucher 

• Pre-Paid Pass 

3. Customized Products 

• Direct Pass Sales 

• Direct Ticket Book Sales 


Travel may be on regular routed service, paratransit, and/or vanpools. For 
vanpools, financial subsidies shall be applied directly to the specific 
vanpool designated by the institution. The Contractor shall coordinate 
with and report vanpool subsidies to the vanpool administrator at the 
participating Agency(s). 

The Contractor shall also provide options to develop new programs in the 
future, including programs that combine features of those listed in Figure 
II-2.1. 

2.1.1.1 Right-to-Ride Pass (e.g. FlexPass) 

The right-to-ride pass shall provide for unlimited use pass privileges by 
employees of an institution on one or more Agency public transportation 
systems The pass privileges will remain in effect until canceled by the 
employer or Agency. 

Data shall be collected for each pass transaction, and may be used to 
compute the basis for payment by the employer. Survey or other data may 
also be used to determine payment basis. 








The RFCS shall provide two right-to-ride pricing alternatives: 


1. Flat Rate Pricing. The Agency and employer negotiate a flat rate 
price for all Agency passes (price will vary by Agency), and update 
the price annually. Data on actual use (recorded pass transactions) of 
Agency services in the previous period is used to update the negotiated 
flat rate price for the following period. 

2. Per Trip Pricing. The Agency and employer negotiate a price per 
trip. Employers are billed based on the actual use (recorded pass 
transactions) of the Agency service at the agreed per-trip price. 

2.1.1.2 Electronic Voucher 

An electronic voucher is the fare card equivalent of the current employer 
sponsored Commuter Bonus Voucher. This program shall provide for a 
fixed dollar amount subsidy to be distributed monthly to participating 
employees. The subsidy is valid for stored value multi-ride or pass 
purchase on any Agency public transportation service at the discretion of 
the employee. 

The actual amount of the subsidy shall be configurable by individual 
employee or groups of employees (e.g. one group may receive a $25 
subsidy while another may receive a $50 subsidy). 

The RFCS shall include the capability of canceling unredeemed vouchers 
under the following circumstances: 

(a) At the direction of the Agencies in the event of non-payment by 
the institution. 

(b) If the voucher has not been redeemed within the month, the 
unredeemed value shall be credited to the institution. 



2.1.1.3 Customized Products 

Customized products refers to the loading of a specified pass or stored 
value amount directly to a card or series of cards through any RFCS 
revalue option. 

An Agency or Institution shall be able to designate (order) the product(s) 
to be loaded, with the card automatically revalued when presented at any 
revalue point in the network. If the product has not been loaded within a 
period specified by the Agencies (e.g. 90 days), the product shall be 
canceled and unredeemed value credited to the institution’s account. 

2.1.2 Campus Program 

Several Agencies have arrangements with local universities and colleges 
to provide faculty, staff and students with public transportation privileges 
in a program that is cost shared with the faculty/students/staff. 

The Contractor shall provide an RFCS fare card Campus Program solution 
that provides public transportation privileges negotiated between the 
Agencies and campus, and is convenient for faculty, student and staff 
participants. The program shall be extensible to other campuses and 
academic institutions, including universities, community colleges, and 
potentially public schools. 

2.1.3 Human Service Program 

Human Service programs currently offer two types of public 
transportation benefits for qualified clients: 

1. Issuance of a period pass for clients who qualify for ongoing public 
transportation benefits. 

2. Issuance of one or more tickets valid for a single trip each. These are 
for clients who qualify for specific short-term public transportation 
benefits only. 

The Contractor shall implement a fare card Human Service subsidy for 
clients who qualify for ongoing public transportation benefits. Alternatives 
shall include those listed in Section 2.1.1 for employer programs. 


The Contractor shall also provide disposable smart card options for single¬ 
trip/short term travel for Human Service Agency clients. 



6.11-2.2 Functional Requirements 

2.2.1 Common Institutional Program Requirements 

The Contractor shall support the following requirements that are common 
to all of the Institutional Programs (DR 2): 

(a) The Contractor shall initialize all fare cards for Institutional 
Program participants with the appropriate customized parameters 
applicable to the Institution and program, subject to the provisions 
of 6.II-4.2.1. 

(b) The Contractor shall utilize Institutional Account identification 
numbers supplied by the Agencies. 

(c) The Contractor shall distribute initialized fare cards to a designated 
Agency responsible for redistribution to the institutions. The 
institution will issue cards to the individual card holders. 

(d) The Agencies shall be provided with functions, systems and 
services to complete initialization and distribute fare cards to the 
institutions. 

(e) The Contractor shall provide program support to the institutions 
including: 

i. Customer Service (per Section 6.II-1) including telephone 
and Internet support. 

ii. Fare Card Management (per Section 6.II-4). 

iii. Clearinghouse Services (per Section 6.II-5). 

iv. Financial Management (per Section 6.II-7). 

v. Network Management (per Section 6.II-8). 

(f) The Contractor shall implement on-going changes to the 
transportation programs of individual institutions as directed by the 
Agencies. These changes shall include: 

i. The addition or deletion of cardholders to the program. 

ii. Changes to the defined fare payment options. 

iii. Changes to the designation of the applicable Agency 
services. 

iv. Changes to the billing cycle. 

v. Cancellation and credit back of unused voucher subsidy or 
fare products. 

vi. Changes in the amount of the institution subsidy for 
immediate or a future effective date. 



vii. Blocking of designated fare cards to prevent further use of 
the Institutional Program application or the entire card. 

viii. Un-blocking of the Institutional Program application for 
employees/students/staff/clients who have re-joined the 
program. 

ix. Blocking, or rendering it otherwise inaccessible, the e- 
purse functionality for specified Institutional card groups. 
Once blocked, the e-purse cannot be unblocked. 

(g) The Contractor shall provide the revalue options identified in 
Section 6.II-9 for institutional program cardholders. 

(h) The Contractor shall be responsible for all transaction data 
processing required to support the billing for Institutional 
Programs. 

(i) The Contractor shall provide a single consolidated invoice or 
billing information to a designated Agency for invoicing to the 
institution as follows: 

i. Flexible billing options that allow the institution to pay 
over time (e.g. partial billing monthly; 50% (a) 30 days, 

50% @ 90 days, etc) 

ii. Billing options shall be at the direction of the Agencies for 
specific institutions. 

iii. The bill shall be broken down by Agency, transaction 
volume, type of transaction, and cost. 

iv. A penalty shall be applied by the agency to any outstanding 
balance due for that invoice. The penalty shall be fixed at a 
rate not to exceed that allowable under State of Washington 
law. Any payment not received by the agency within thirty 
(30) days of receipt of a billing invoice is past due. 

(j) The Contractor shall provide the following mechanisms for an 
institution to manage and update card accounts, and order/update 
products: 

i. A secure Internet Website as described in Section 6.II- 
1.2.5. 

ii. Through transfer of an electronic file of card serial number, 
privileges and products. 

(k) Card and account management and update features shall include: 

i. The capability of transmitting program changes to the 
clearinghouse system on a scheduled and un-scheduled 
basis. 



ii. The ability to generate reports from the clearinghouse 
database on the status of all cards, voucher subsidies, and 
product loads. 

iii. The ability for Commercial Accounts to generate reports 
from the Clearinghouse data base to determine their 
employee use. 

(l) The Contractor shall provide campus and human services 
institutions with the capability to carry out fare card imprinting 
with logos/graphic information and/or 
employee/student/staff/client photographs. 

(m) The Contractor shall provide systems and procedures to maintain 
confidentiality and privacy on the use of individual fare cards, to 
be accessible only by the Agencies or institution. 

2.2.2 Specific Institutional Program Requirements 

2.2.2.1 Right-to-Ride Program (DR 2.01) 

(a) The Right-to-Ride Program fare card shall be initialized to indicate 
the program type and as an unlimited use pass on one or more 
Agency transportation services. 

(b) Right-to-Ride cards shall have the capability of establishing a limit 
on fare transaction value (policies to be established by the 
Agencies and Institution). 

(c) An employee may add additional value to his/her fare card at any 
device in the revalue network, to enable the fare card to be used as 
fare payment for the services provided by other Agencies not 
covered by their employer’s program. 

(d) Agreements between the Agencies and institutions may include 
other products and services that are billed directly by the Agencies. 
Billing for RFCS products shall be separate from that of other 
products and services. 

2.2.2.2 Electronic Voucher Program (DR 2.02) 

(a) The Electronic Voucher Program fare card shall be initialized to 
indicate the program type, the amount of the monthly revalue 
subsidy and the effective date of the beginning of the monthly 
period. 

(b) The monthly period may be set by individual employers and need 
not be based on a calendar month. 



(c) When an employee revalues his/her fare card at any revalue point 
in the network, the subsidy amount shall be deducted from the 
gross cost of the revalue. The subsidy is applied towards 
transportation services for fare payment options selected by the 
employee. The remaining revalue amount is paid by the employee 
at the revalue point. 

(d) The subsidy will be applied only once a month and will be 
activated at the beginning of the effective period. 

(e) The subsidy shall be canceled and the value credited to the 
institution account if not redeemed within a pre-defined timeframe 
(variable parameter to be determined by the Agencies). 

2.2.2.3 Customized Product Program (DR 2.03) 

(a) An institution shall be able to order specific RFCS passes, multi¬ 
ride or stored value amounts for identified cards. 

(b) The RFCS shall automatically load the specified pass or stored 
value amount at any revalue point in the network when the card is 
presented. 

(c) The product shall be applied only once. 

(d) The product shall be canceled and the value credited to the 
institution account if not redeemed within a pre-defined timeframe 
(variable parameter to be determined by the Agencies). 

2.2.2.4 Campus Program (DR 2.04) 

(a) The Campus Program fare card shall be initialized to indicate the 
program type and as an unlimited use pass on a designated Agency 
transportation service or services, and may have an activation date 
which defines when the privilege will begin and/or an expiry date 
which defines when the privilege will end. 

(b) Students/staff/faculty who decline to participate in the program 
shall have the Campus Program function blocked on their fare 
card. Participants who decide to re-join the Campus Program shall 
have the Campus Program function un-blocked on their fare card. 
These changes shall be accomplished without requiring the 
affected students or staff to present their fare card to a revaluing 
device. 

(c) A student/staff/faculty member may add additional value to his/her 
fare card at any device in the revalue network, to enable the fare 
card to be used as fare payment for the services provided by other 
Agencies not covered by their Campus Program. 



(d) The subsidy shall be canceled and the value credited to the 

institution account if not redeemed within a pre-defined timeframe 
(variable parameter to be determined by the Agencies). 

2.2.2.5 Human Service Programs (DR 2.05) 

(a) Human Service Agencies shall have the ability to issue cards and 
provide transportation benefits to clients (customers) as follows: 

i. By issuing an unvalued fare card and using the Internet 
Website to order the voucher or fare product to be loaded, 
or register the card for Right-to-Ride privileges, with the 
card updated the next time it is presented at a revalue 
location or FTR It is expected that the Customized Product 
option will be the most widely used. 

ii. By issuing pre-valued disposable smart cards from a stock 
maintained in the Human Service Agency office. 

(b) The Internet Website shall also be used for: 

i. Ordering replacement fare card or disposable card stock. 
Orders shall be forwarded to a designated Agency for 
fulfillment, and associated with the specific Human Service 
Agency office placing the order. 

ii. Card and account management and reporting functions for 
caseworkers and supervisors. Different levels of account 
management and access shall be provided for caseworkers 
and supervisors, to be determined at Final Design Review 
(CDRL 3). 

(c) Billing/invoicing information shall be generated by specific 
Human Service Agency office. 

(d) Electronic files (ASCII flat file format) of billing/invoice 
information shall be generated for the designated Agency that 
invoices the Human Service Agency. 

(e) The Internet Website shall allow a card to be “de-associated” from 
the Human Service Agency when benefits have expired, and used 
by the customer as a general public RFCS card. 

6.11-2.3 Performance Requirements 

The Contractor shall provide implementation solutions for the Institutional Programs 
which: 


(a) Automate program administration to the extent feasible, and provide the 
necessary software, training and other systems for automation. 



(b) Reduce administrative effort for the participating institutions, including 
establishing the program, administering individual cardholder changes, and 
billing. 

(c) Provide timely and easily accessible data on the use of Agency services by 
employee/student/faculty/staff/client participants. This includes both summary 
and individual card use data. 

(d) Are suitable for both large and small institutions. 

(e) Allow the institution to include other, non-transportation applications on the 
card to support other aspects of their business. 

6.11-2.4 Invoicing and Funds Collection Services (Option) 

The Contractor shah propose an option to provide additional institutional program 

invoicing and funds collection services on behalf of the Agencies as follows: 

(a) The Contractor shah provide invoicing and funds collection on behalf of the 
Agencies for employer, commercial account, campus and human service 
programs. The Agencies will bear the risk of loss of unpaid funds, provided 
that the Contractor exercises reasonable efforts to collect funds and mitigate 
such loss. 

(b) The Agencies shah retain contractual arrangements and authority with 
institutions regarding program operation, pricing and obligations. 

(c) Institutions shah be provided with pre-and post-payment options per the 
direction of the Agencies. 

(d) Invoices shah be generated by institution and specific office or location, and 
shah include ah RFCS products, value and amounts owing during the 
invoicing period. 

(e) The Contractor shah provide A/R and A/P support to institutions through the 
Internet website, telephone and mail. 

(f) Ah receivables shah be maintained at thirty (30) days or less. 

(g) In the event that a receivable governed by an Agency-Institution agreement 
extends beyond 30 days, the Contractor shall notify the Agency within two (2) 
business days. 

(h) The Contractor shah adhere to cash management practices per the 
requirements of the Washington Office of the State Treasurer and Office of 
Financial Management. 

(i) A11 proposed fees shah be subject to approval by the Contract Administrator. 



Figure 11-2.2: Estimated Institutional Programs and Media Volumes 


Current Account Type 

Approximate # 
of Accounts 

Approximate Annual 
Volumes (Notes 1,2) 

Community Transit 

1. Employer Accounts 
• Monthly Passes 

14 

18,000 passes 

• FlexPass 

- 

Included in KCM #’s 

2. Ed Pass (campus) 

1 

Max 10,000 passes per 

3. Campus Card 

_ 

quarter 

Included in KCM #’s 

Everett Transit 

1. Employer Accounts 
• Monthly and WSF/ET passes 

5 

10,000 passes 

• Consignment Passes 

5 

1700 passes 

2. Human Service 

20 

500 passes 

King County Metro 

1. Employer Accounts 
• Pre-paid Passes 

300 

40,000 passes 

• Consignment Passes 

200 

350,000 passes 

• FlexPass 

125 

90,000 passes 

• Commuter Bonus Voucher 

400 

$2,600,000 

2. Campus Card 

2 

60,000 passes 

3. Human Service 

130 

60,000 ticket books 

Kitsap Transit 

1. Employer Accounts 
• Consignment Passes 

26 

4,400 passes 

2. Human Service 

6 

5,800 passes 

Pierce Transit 

1. Employer Accounts 
• Consignment Passes (Note 1) 

105 

87,000 passes 

2. Human Service 

6 

4,000 passes 

Washington State Ferries 

1. Employer Accounts 
• Pre-paid Passes 

18 

700 passes 

• Consignment Passes 

15 

4,400 passes 

• Commuter Bonus Voucher 

4 

$1,800 

2. Commercial Accounts 

1,980 

168,000 transactions 



$6,000,000 


Note 1: Does not include youth passes. 
Note 2: Includes Puget Passes. 
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6.11- 3 Card Procurement and Distribution 

6.11- 3.1 Card Procurement and Distribution Description 

(a) The Contractor shall procure fare cards and disposable fare cards on behalf of 
the Agencies in accordance with the specifications in Section 6.III-2 (DR 3). 

(b) Cards shall be procured in sufficient quantity to provide the most favorable 
cost to the Agencies and to meet the demands for fare cards throughout the 
region. The Agencies will provide demand forecasts for cards. 

6.11- 3.2 Functional Requirements 

3.2.1 RFCS Card Procurement 

(a) The Contractor shall provide RFCS cards according to the 
specifications defined in Division III, Section 6.III-2. 

(b) The base cards shall be procured with the specified artwork and 
logo of the RFCS program. 

(c) Upon receipt of the card order by the Contractor, the chip shall be 
loaded with the RFCS application and security keys (initial 
initialization). 

(d) Quality assurance measures shall be implemented by the 
Contractor to ensure that a card batch meets the quality and 
performance standards defined in Section 6.III-2. 

(e) Defective cards shall be returned to the manufacturer and 
replacements procured by the Contractor. 

3.2.2 RFCS Card Distribution 

(a) The Contractor shall distribute cards to a designated central 
inventory and fulfillment location as designated by the Contract 
Administrator. 

(b) Cards shall be shipped to the designated Agency central location in 
a blocked condition. 

(c) Card orders shall be accompanied by (DR 3.01): 

i. Order confirmation and invoice or purchase order 
reference. 

ii. A packing slip and other shipping documents as required. 

iii. Back order and/or replacement card information. 




iv. Quality assurance test results and card defect statistics. 

v. An electronic file cross-referencing electronic serial 
numbers with printed card serial numbers. 

vi. Other data as required in paper and electronic form for 
central Agency inventory control. 

(d) The Contractor shall be responsible for the physical security of 
inventory and risk of loss until received at the designated Agency 
location. 

(e) The Contractor shall be responsible for all shipping and insurance 
costs. 

3.2.3 RFCS Card Inventory Management 

(a) The Contractor shall be responsible for managing RFCS Card 
inventory prior to shipment to the designated Agency location. 

(b) Upon receipt of card stock from the manufacturer and initial card 
initialization, the Contractor shall record all card serial numbers in 
the RFC system. 

(c) The Contractor shall provide statistical reports detailing the 
procurement and distribution of cards. 

6.11- 3.3 Performance Requirements 

(a) Contactless Only cards and Disposable cards shall be delivered to the 
designated central inventory location within ninety (90) days of ordering. 

(b) King County Metro Employee ORCA ID cards shall be delivered to the 
designated central inventory location within one hundred eighty (180) days 
of ordering. 

6.11- 3.4 Additional Card Procurement and Inventory Functions (Option) 

The Contractor shall propose an option to provide additional card procurement and 
inventory functions as follows: 

(a) The Contractor shall maintain the central inventory of RFCS fare cards and 
disposable cards. 

(b) The Contractor shall be responsible for distributing card inventory to Agency 
customer service offices and other designated card issuance locations. 

(c) The Contractor shall accept card orders from an Agency or other designated 
card issuance location. 

(d) The Contractor shall be responsible for providing all card initialization, 
personalization and linking functions for cards and card batches issued by the 



Contractor. The Agencies will provide final setup and card personalization for 
cards distributed through Agency customer service offices. 



(e) The Contractor shall track all card inventory from procurement through 
issuance. 

(f) The Contractor shall monitor card stock at all issuance locations, and notify 
the issuance location when minimum inventory levels are reached. 

(g) The Contractor shall maintain the physical security of cards until distributed 
to issuance points. 

(h) The Contractor shall prepare monthly reports of the procurement and 
distribution of all card inventory. 

(i) The Contractor shall deliver FOB destination single card orders within forty- 
eight (48) hours, small batch orders (<100 cards) within seven (7) days, and 
large batch orders (>100 cards) within fourteen (14) days. 

(j) All proposed fees shall be subject to approval by the Contract Administrator. 

6.11-3.5 Local Inventory System 

The Contractor shall provide the Agencies with the ability to access and use the 

Contractors inventory system for local inventory management of fare cards as 

follows: 

(a) The inventory system shall provide capabilities for a designated Agency to 
receive, manage, track and distribute central card inventory at a designated 
central distribution point in the Central Puget Sound Region. 

(b) The inventory system shall provide capabilities for each Agency to receive, 
manage, track and distribute card batches shipped to local agency distribution 
sites. 

(c) The inventory system shall provide capabilities for the central card inventory 
site or local Agency sites to track and distribute cards sent to card issuance 
locations. 

(d) The inventory system shall be integrated with inventory capabilities of the 
Customer Service Terminal, and shall be updated as cards are received and 
issued at card issuance locations. 
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6.11- 4 Fare Card Management 

6.11- 4.1 Fare Card Management Description 

The RFCS application is a specific set of functions which will be enabled through use 
of the RFCS fare card and which the Contractor shall support according to the terms 
of this Contract. Additional applications may optionally be loaded on the card which 
will require additional storage capacity and capability. This section describes the 
information and functionality that the Contractor shall support for the RFCS 
application. 

Through the Customer Service Terminal (Section 6.III-10), Internet website (as 
applicable), or electronic data transfer from other systems, the Contractor shall 
provide the software and services necessary for card management functions, which 
includes tracking all distributed cards, maintaining a current status and history of card 
use, maintaining a database of information contained on the card and maintaining 
current account balances for each card (DR 4). 

6.11- 4.2 Functional Requirements 

4.2.1 Card Initialization 

(a) The Contractor shall provide the capability to unblock a card and 
complete the initialization process at the time of issuance. Card 
initialization parameters shall include at a minimum: 

i. Fare category, privileges, and other cardholder-specific 
information 

ii. Automatic revalue provisions 

iii. Institutional account ID, parameters and options 

(b) The Contractor shall provide the capability to order cards for 
specified Institutional card groups with e-purse blocked or 
otherwise inaccessible. The e-purse block shall not prevent 
cardholders from loading any other fare products on their cards. 

4.2.2 Card Information 

The card management system shall, at a minimum, include the following 
information, and shall have capabilities to add additional data elements in 
the future (DR 4.01). These are data elements that it is envisioned will be 
recorded and stored by the clearinghouse system. The data elements to 
reside on the card are described in Section 6.III-2.4.3. 

(a) Each card shall have a unique card identifier. 

(b) Card Status 




1 . 


Initialized / un-initialized 

ii. Card Block / unblock 

iii. Application or function block / unblock 

iv. Linked / anonymous 

v. Date issued 

(c) Card Privileges / Options / Restrictions 

i. Automated revalue 

ii. Maximum card value 

iii. Limited routes / periods of usage 

iv. Bonus programs 

v. Frequent user programs 

vi. Other applications 

(d) Fare Category 

i. Adult (Base) 

ii. RRFP (Permanent and temporary w/expiry date) 

iii. Low income and low income family (for KT) 

iv. Date of birth (for automated fare group management and 
“youth” fare) 

v. WSF vehicle types 

(e) Card Ownership 

i. Other institutions 

(f) Linking Information 

i. PIN (number or password) 

ii. Name (not on fare card - only in central database) 

iii. Address (not on fare card - only in central database) 

iv. Phone number (not on fare card - only in central database) 

v. Photo (RRFP, institutional programs as required) 

vi. Physician’s name (RRFP; not on fare card - only in central 

database) 

(g) Card Transaction History 

i. Fare payments and transfers (minimum previous twenty in 
the database) 

ii. Status/options/privilege changes 



(h) Automatic Revalue Information 

i. Revalue threshold 

Period pass - type, validity/activation date, and expiration 
date 

Multi-ride - type, validity/activation date, and expiration 
date 

Stored value - dollar amount 
Electronic Voucher - dollar amount 

ii. Credit card account number (not on fare card - only in 
central database) 

iii. Debit card account number (not on fare card - only in 
central database) 

iv. Direct debit bank information (not on fare card - only in 
central database) 

v. Autoload (Electronic Voucher or Customized Product) 
status - pending, loaded, expired (not on fare card - only in 
central database). 

(i) Not Sufficient Funds (NSF) History 

(j) Current Account Balances 

i. Stored value (dollar value with a configurable maximum). 
The Contractor may identify a maximum purse value 
consistent with their business strategy. 

ii. Passes (fixed period [e.g. day pass, weekly pass, two week 
pass, calendar month, etc.] or rolling period [e.g. 7, 14, 28, 
30, 90, 365 days, etc.]) 

iii. Multi-rides (maximum and number remaining, validity 
period) 

4.2.3 Card Management 

(a) The Contractor shall maintain the central electronic database of all 
RFCS card accounts. The database shall be maintained while the 
card is in active status or for a minimum ninety (90) days, 
whichever is greater, before archiving. 

(b) The Contractor shall describe processes for accessing archived 
card account data (DR 4.02). 

(c) The Contractor shall provide a database structure to meet all card 
management requirements. 



(d) The Contractor shall provide software and systems to access card 
accounts for additions, updates, and queries. 

(e) Specific card management requirements shall include: 

i. Establish cardholder account at card issuance. 

ii. Establish cardholder account for card replacement. 

iii. Cardholder value replacement for malfunctioning card. 

iv. Cardholder linking for those customers choosing to link 
their cards. 

v. Maintain cardholder options and privileges. 

vi. Maintain current card account balance. 

vii. Maintain card transaction history. 

viii. Maintain card application and configuration information. 

4.2.4 Privacy 

The Contractor shall implement systems and procedures which are 
consistent with Agency public disclosure policies, and that ensure the 
privacy of cardholder personal information. The systems and procedures 
shall also ensure the privacy of the card owner, in the event that the card 
owner is different than the cardholder. 

6.11-4.3 Performance Requirements 

(a) The Contractor shall initialize and distribute cards within one (1) working day 
of request. 

(b) The Contractor shall implement quality assurance steps which ensure the 
accuracy of information stored on the card and in the database. Quality 
assurance steps are subject to approval by the Contract Administrator. 

(c) Contractor shall track and manage card failure rates per the requirements of 
Section 6.III-2. 

(d) All card updates shall be transmitted to the revalue network within twenty 
four (24) hours and to the data acquisition systems within twelve (12) hours of 
recording of the transaction by the clearinghouse system. 
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6.11- 5 Clearinghouse Services 

6.11- 5.1 Clearinghouse Services Description 

The clearinghouse services includes the central management and control functions 
necessary to implement and operate the RFCS. The following is a summary list of 
these responsibilities. 

• Provide transaction processing, and act as final transaction acquirer and 
processor of all system transaction activity. 

• Reconcile and settle all transactions. 

• Manage data upload and download between the clearinghouse system and all 
end points. 

• Manage system interfaces and all end points. 

• Manage fare table updates. 

• Detect and manage fraudulent activity. 

• Provide the central database for system reporting, and provide standard and 
ad-hoc (user defined) reports to RFCS participants. 

• Maintain and operate all central clearinghouse system databases required for 
RFCS operations. 

• Provide and support system audit. 

6.11- 5.2 Functional Requirements 

5.2.1 Transaction Processing 

5.2.1.1 General Processing Requirements 

The Contractor shall provide the following general processing functions, 
(a) Complete audit trail of all system activity. 


(b) Database backup, reorganizations, tuning, and other necessary 
database management functions. 





5.2.1.2 Daily Transaction Processing Functions 


5.2.1.3 


The Contractor shall provide the following daily transaction processing 
functions (DR 5.01): 

(a) Financial reconciliation 

(b) Settlement 

(c) Reports 

(d) Card initialization processing 

(e) Card account management including at a minimum escheat, 
dormancy, stale accounts, write-offs, adjustments 

(f) Credit / debit revalue transactions 

(g) Cash management activity (such as settlement with credit / debit 
networks, check processing and clearing, other payment 
processing, matching receipts with revalue transactions. See 
Section 6.II-7.) 

Daily Processing Cycle 

(a) The Contractor shall provide systems, software, and on-going 
operations to meeting all clearinghouse system processing 
requirements. 

(b) The RFCS shall operate on a daily processing schedule 7 days per 
week, 365 days per year. 

(c) At a minimum of once per day, providing the transaction endpoints 
connect into the appropriate RFCS network point, all transactions 
shall be uploaded to the clearinghouse system from these 
endpoints. 

(d) Once database updates are completed, the following daily 
processing cycle functions shall be performed: 

i. Revenue reconciliation and settlement. The Contractor 
shall define a schedule to provide next day settlement to all 
Agencies. 

ii. Report generation and management services. Reports shall 
be available by the next day. 

iii. Data download to respective endpoints; e.g. reports to 
Agencies, ACH file to settlement bank, blocks, function 
blocks, fare table changes, parameter table changes, etc. to 



DACs, and other revalue devices. All downloads shall be 
completed by 4 a.m. Pacific time the following morning. 

(e) The Contractor’s daily business cycle shall not end before 6 p.m. 
Pacific time. 

(f) The Contractor’s daily business cycle shall not impact existing 
CSO operations and daily processing. 

(g) The Contractor shall map RFCS transactions to each Agency’s 
daily business cycle irrespective of the clearinghouse system 
business cycle. 

5.2.2 Reconciliation and Settlement 

(a) The Contractor shall, at the end of each twenty four hour business 
cycle, close out the day’s activity, reconcile account balances, 
calculate revenues due each participating Agency, and initiate 
settlement funds movement to and from designated Agency 
accounts (DR 5.02). 

(b) Settlement to the Agencies shall be done on a cash basis per the 
requirements of Section 6.II-7. 

(c) The RFCS shall provide next business day settlement of available 
funds. 

(d) Settlement data shall be transmitted to the Agencies by 6 a.m. 
Pacific time the following business day 

(e) Revenue shall not be settled until the funds for the transaction are 
received (or memo posted in the event funds are received and held 
in an Agency account) by the clearinghouse system. 

(f) Daily fare reconciliation shall take into account all transactions 
with a financial impact. This shall include as a minimum: 

i. Revalue transactions. 

ii. Fare payment transactions. 

iii. Revalue and fare payment cancellation. 

iv. Value replacement for lost and stolen cards. 

v. Adjustments, escheatment and write off transactions. 

vi. Payments from institutional programs. 

(g) The Contractor shall reconcile daily all fee revenue paid to or 
received from acquirers and/or financial networks, deposits/fees 
held for RFCS cards. 



(h) The Contractor shall initiate daily settlement transactions to each 

Agency. The Contractor shall use a method for settlement, such as 

ACH or wire transfers or intra-bank money transfers. 

(i) Daily reconciliation shall provide the following: 

i. Reconcile daily batch totals to transaction totals. 

ii. Reconcile all daily receipts to accounts receivable (revalue 
network, credit and debit networks, institutional 
programs). 

iii. Reconcile cardholder account balances, the beginning 
balance, the net value of all transactions posted to the 
account, and the ending account balance. 

iv. Reconcile the total value of fare revenue due to 
participating Agencies to the value of fare revenue 
recognized for the processing day. 

v. Reconcile the total funds due from participating 
institutional programs to the appropriate fare card 
applications. 

vi. Reconcile the total funds entering, exiting, and remaining 
in the system each day. 

vii. The Contractor shall calculate the daily settlement due each 
Agency. Specific revenue sharing processing rules shall be 
provided to support this calculation, but at a minimum, the 
following shall apply: 

- Revenues are settled based on number and type of 
transactions. 

- For fare media (including e-purse) that are valid at 
more than one Agency, the Agencies will defer revenue 
for one month (or whatever timeframe is considered 
practical) and use actual date to adjust/settle the 
amounts. 

- Upon sale of all multi-Agency passes or passes of 30 
days or less in duration (i.e. weekly or daily), pass 
revenue will be distributed at the end of the pass period 
based upon actual usage. 

- For monthly multi-Agency, period (multi-month) 
passes, revenue will be distributed in equal monthly 
amounts (i.e. 1/12 for annual, 1/3 for quarterly) based 
upon a pre-defined allocation formula to be supplied by 
the Agencies. 

- For fare media that are valid exclusively at an agency, 
or where the amount received by an Agency is a flat 



(predetermined) amount, the Agencies will receive all 
revenues on the day that the purchase transaction is 
complete. 

- Interest earned on RFCS funds is shared between 
Agencies with a formula to be determined by the 
Agencies. 

(j) The Contractor shall compute, on a daily basis, the allocation of 
costs to each Agency according to formula provided by the 
Agencies. 

(k) The Contractor shall administer a claims fund held in an account 
designated by the Contract Administrator (DR 5.03). The claims 
fund shall be used to settle revenue for lost transactions or 
transactions that otherwise cannot be reconciled. Transactions will 
be considered expired if they have not cleared and funds will then 
be transferred into the claims fund. 

5.2.3 Data Upload and Download (DR 5.04) 

5.2.3.1 General Upload and Download Management 

The Contractor shall provide the following data upload and download 
functions: 

(a) Transfer of transactions utilizing batch files. 

(b) Batch validation and management 

i. All batches received 

ii. Required software version loaded 

iii. Validate source of batch 

iv. Duplicate detection 

v. Batch consistency (details match header data) 

vi. Batch data archive 

vii. Security enforcement 

(c) Transaction validation and management 

i. Data field edit checks 

ii. Transaction consistency checks 

iii. Validity of card serial number 

iv. Validity of card status 

(d) Execute any exception / error handling processes 



(e) Update database 

(f) Post account balances 

(g) Implementation of upload and download processes 

i. Implementation of security processes 

ii. Re-transmission as necessary 

iii. Assurance that all endpoints have received downloads 

5.2.3.2 Data Upload (Transaction Acquiring) 

RFCS is envisioned primarily as an off-line accountable system with 
transaction data being collected by remote processors or transaction 
devices, assembled in transaction batches, and depending on the specific 
interface, but typically once per twenty four hours, is submitted to the 
clearinghouse system. 

The Contractor shall be responsible for accurate and timely acquiring of at 
least the following transaction batches. In addition, there are on-line 
interface requirements for certain administrative transactions between the 
central system and the customer service offices and the Contractor’s call 
center. 

(a) Off-line batch transactions shall include: 

i. Fare payment transactions 

ii. Revalue transactions 

iii. Cancellation and reversal transactions 

iv. Confirmation of blocks, option changes, and revalues 

v. Fare table updates 

vi. Credit and debit card settlement files 

(b) Administrative transactions - both on-line to central system 
database and in off-line batch transaction mode - shall include: 

i. Account set up 

ii. Initialize and issue fare cards 

iii. Updates to account information 

iv. Balance inquiries 

v. Revalue cards 

vi. Provide card balance information 

vii. Provide previous transaction information 



viii. Report lost/stolen or malfunctioning cards - card and 
function block 

ix. Function and card Unblock 

x. Change cardholder options / privileges 

xi. Card replacements (restore balance) 

xii. Collect/update cardholder personal identifying information 

xiii. Link fare card using a PIN 

xiv. Enroll in automatic revaluing program 

xv. Process customer initiated (phone and mail) revalue 
requests 

xvi. Problem reporting 

xvii. Authorize card value refunds and replacements 

xviii. Card value adjustments 

(c) The Contractor shall include in the RFCS a Transaction Expiration 
period (the period after which a transaction will be considered as expired 
and will not be settled), and a Deferred Refund/Replacement period (the 
period at which the system calculated value that can be refunded or added 
to a replacement card). These periods shall be set to seven (7) days for 
both. 

(d) The Contractor shall provide capabilities of the reporting of all batch 
transaction interfaces including: 

i. Any transactions rejected for failing integrity checks, 
including duplicate detection. 

ii. Missing transactions (gaps) from any device 

iii. Secure logging of all incoming transactions and a complete 
audit trail of all transaction-based activity 

The Contractor will also provide backup procedures for 
uploading transactions in the event that the primary data 
path is unavailable of fails. 

(e) The Contractor shall implement and operate an on-line interactive 
transaction interface to support CSOs and the call center operation. This 
interface shall be used for the set of administrative transactions listed 
above. 

5.2.3.3 Data Download (From Clearinghouse System) 

(a) The Contractor shall transmit on a scheduled basis information to 
the end points necessary for operations. 



(b) The Contractor shall provide a solution which minimizes the time 
frames between when new card or function blocks and automated 
revalues are processed at the central system and are available at the 
point of service. 

(c) Devices receiving transmissions from the clearinghouse system 
shall include as a minimum: 

i. DACs 

ii. Fare Transaction Processors 

iii. RFCS equipment installed in Sound Transit TVMs. 

iv. Agency CSOs and the call center 

v. Other devices in the revalue network 

vi. Agency back-office systems 

vii. Institutional Program participants 

viii. Settlement bank 

(d) The following types of transactions and information flow shall be 
supported: 

i. Function and card blocking and unblocking 

ii. Revalue orders including electronic vouchers or voucher 
updates, and fare products (passes, multi-rides, stored 
value). 

iii. Fare tables 

iv. Reversals of automatic revalues 

v. Privilege and option changes / cancellations 

vi. Reports 

vii. Transaction logs 

viii. Database off load 

ix. ACH settlement transactions 

(e) The Contractor shall provide capabilities for the management of all 
download interfaces. 

i. Schedule for downloading to all end points. 

ii. Procedures for download management - ensure integrity. 

iii. Process to guarantee successful downloads to all end points 
according to the pre-determined schedule. The process shall 
include error handling, retransmission protocols, 
acknowledgments, data reconciliation procedures, batch 
validation. The Contractor shall develop procedures to 



ensure that all fare table and other operational parameter 
changes are downloaded and installed in all FTP and 
revalue devices in accordance with the schedule 
requirement for their implementation. 

iv. Duplication detection - download batch management and 
tracking. 

v. Complete audit of all outgoing transactions. 

vi. Backup procedures for daily downloads in the event the 
primary procedure is unavailable or fails. 

(f) The Contractor shall be responsible for initiating and processing 
credit and debit card approval transactions based on incoming 
automatic and customer requested revalue transactions. 

5.2.4 System Interface and End Point Management (DR 5.05) 

5.2.4.1 Systems Interfaces and End Points 

The Contractor shall design, implement and support the following systems 
interfaces between the clearinghouse system and the following RFCS end 
points. 

(a) Data Acquisition System - Upload fare payment transactions, 
automated revalues, block and revalue acknowledgments. 

Download blocks, unblocks, revalues, status or privilege changes, 
fare tables, and other operational parameter data as required. 

(b) Revalue network and Fare Transaction Processors - Upload revalue 
transactions and fare card re-supply requests. Download fare tables 
and other operational parameter data as required. 

(c) Customer Service Terminals - Provide on-line transaction 
interfaces for administrative functions. 

(d) Agency Back Office Integration Application - receive Agency fare 
table updates, send reports and Agency specific transaction data for 
further analysis. 

(e) Call Center - provide customer service functions by the 
Contractor. 

(f) Institutional Programs - receive card initialization requests, card 
cancellations, function and card blocks, and manage billing, 
payments and reporting. 

(g) Commercial Credit Card Network - act as merchant acquirer to 
receive on-line authorizations for credit card revalue purchases and 
to receive financial settlements. 



5.2.4.2 


(h) Debit Card Network - act as merchant acquirer to receive on-line 
authorizations for debit card revalue purchases and to receive 
financial settlements. 

(i) ACH - implement money movement to and from the Agencies in 
support of the settlement process. 

(j) Internet and/or other revalue methods identified by the Contractor - 
provide account setup, card initialization, revalue, balance inquiry, 
transaction history, and status inquiry transactions. 

System Interface and End Point Management 

The Contractor shall maintain a database of all system interfaces and end 

points, and for each shall provide the following management functions: 

(a) Security: 

i. Maintain valid user id and passwords. 

ii. Validate all system logon and usage activity. 

iii. Maintain encryption keys necessary for transmission and 
decryption of secured data. 

iv. Maintain transaction privileges valid for each end point. 

v. Develop recovery plan in the event of a security breach. 

(b) Transaction validation: 

i. Assure all transactions originate from a recognized end 
point, using a recognized and valid card with privileges 
appropriate to perform that transaction type. 

(c) Transaction logging: 

i. Provide a complete transaction history for each end point, 
suitable for ad hoc inquiry. 

(d) Interface protocols: 

i. Maintain table of interface management information 
including interface frequencies, communications 
management (which partner initiates communications), date 
and times for expected batch transmissions, contact points, 
and communications protocols. 



(e) Software management: 

i. Maintain “load images” of application data suitable for 
download to update the Contractor provided software in 
transaction devices and other interface points. 

ii. Maintain complete download history and current release of 
software. 

(f) Transaction batch management: 

i. Maintain information on last ‘n’ transaction batches 
received from each end point and provide processing 
algorithms to assure all available transactions are received 
on a twenty four hour cycle. 

ii. Provide capabilities to detect duplicate or incorrect batches 
and provide error handling procedures. 

5.2.5 Fare Table Management (DR 5.05) 

The clearinghouse system will periodically receive manually entered fare 
table updates, pass revenue allocation formula updates and operational 
parameter updates (collectively referred to as “regional data”), as well as 
Agency-specific schedule data updated (“schedule data”), as required for 
RFCS operation. 

(a) The RFCS shall include capabilities to accept and validate 
incoming data updates from the Agencies, store multiple releases 
of them, and format and download them to all endpoints as 
needed. 

(b) The system shall include capabilities for Agency staff to test all 
data updates prior to distribution to system endpoints. Update 
testing capabilities shall include at a minimum: 

i. Data integrity checks. 

ii. Local Agency testing of updates to verify that fare 
transactions are correctly processed, and that revenue and 
data are correctly reported. 

iii. Testing of updates on a regional basis to verify that inter¬ 
system transactions are correctly processed, that other 
Agency data and systems are not adversely impacted, and 
that revenue and data are correctly reported. 

(c) The RFCS shall store a minimum of three sets of data: Prior, 
current and those (as applicable) for future effective date of 
activation. 



(d) 


(e) 


(f) 


(g) 


5.2.5.1 


(a) 


(b) 


(c) 


5.2.5.2 


The RFCS shall include features to replace, as required, regional 
data and schedule data if a new device is installed or a device 
requires replacement information. 

The Contractor shall provide a solution for the coordination and 
timing of the downloads so that data updates are implemented 
uniformly system wide, according to the effective date of the 
updates. The description shall include methods to ensure 
successful delivery to all affected end points. 

The RFCS shall include a configurable parameter, in units of days, 
that specifies a minimum standard separation or “distribution 
interval” between regional data update effective dates, subject to 
approval by the Contract Administrator. The parameter shall not 
constrain the timing of schedule data updates (as described in 6.II- 
5.2.5.2 below) with respect to the schedule data updates of other 
agencies. 

Provisions shall be included in the distribution interval to allow 
“emergency” or other critical data updates to occur immediately or 
with a separation less than the standard distribution interval. 

Regional Data Updates 

Regional updates shall contain individual Agency data from 
previous sets of data if there have been no schedule or other 
updates by the Agency. The RFCS shall include functionality for 
Agencies to update the test regional data. 

The RFCS shall manage regional data to support an automated 
change from current to future data on each endpoint on the Agency 
specified effective date. 

The RFCS shall include provisions to manually enter in schedule 
data as described in 5.2.5.2 below. Such manually entered data 
shall be considered regional data per the provisions of this section. 

Schedule Data Updates 


(a) Schedule data will be provided by the Agencies in an electronic 
file, and will include data such as run, parent route, route variant, 
trip location and associated data required to support RFCS 
functions. This data will be provided on a more frequent basis 
than regional data updates. 

(b) The RFCS shall include functionality to import schedule updates 
from Agency-supplied files using a system administration tool on 
an as-needed basis. 



(c) The RFCS shall provide functionality to test Agency-specific 
schedule updates prior to downloading to any affected endpoints. 
Such updates shall not impact regional data or schedule data from 
any other Agencies, and shall not require testing on a regional 
basis. 

(d) All schedule updates shall include an effective date from which the 
update shall become active on all affected endpoints. 

5.2.6 Fraud Management (DR 5.07) 

(a) The Contractor shall provide regular fraud management reports. 

(b) The Contractor shall develop procedures to detect and/or avoid any 
inappropriate or fraudulent use of the system. Possible solutions 
can include software products which look for anomalous 
transaction patterns such as: 

i. Card groups or types consistently overdrawing available 
balances 

ii. Individual card accounts that are regularly overdrawn or 
have regular fare underpayments 

iii. Inconsistent card use patterns 

iv. Frequency and usage inconsistencies 

v. More than one card with same serial number 

5.2.7 Reporting 

The Contractor shall be responsible for the creation of reports as defined 
in Section 6.III-13, Back Office Data Integration and Reporting. 

5.2.8 Database Management (DR 5.08) 

(a) The Contractor is responsible for support and maintenance of the 
databases necessary for access to RFCS information resources. 

(b) The RFCS shall manage data access requirements, and the 
integration and linking of data elements so as to provide a seamless 
management view of all data resources. The Contractor shall 
provide a solution for protecting access to Agency privileged 
information to that Agency’s staff, and to personal information 
provided for card linking. 

(c) Logical collections of data to be managed by the Contractor shall 
include as a minimum: 

i. End Point Database 

ii. Transaction Batch Management Database 



iii. Card Account Database 

iv. Card Linking Database 

v. Card Account Transaction History 

vi. Transaction Acquirer History Database 

vii. Security and Access Control Database 

viii. Cash Management Database 

ix. Financial Settlements Database 

x. General Accounting Database 

xi. Fare Table Database 

xii. Operational Parameters Database 

xiii. Reports Archive 

xiv. Customer Service Tracking and Management Database 

xv. Historical Database of Blocked and Inactive Cards 

(d) The Contractor shall provide services and facilities for the regular 
backup of all data, off site archiving, ad hoc report queries, and 
disaster recovery (CDRL 5). 

(e) Data shall be maintained for a minimum of ninety (90) days before 
archiving. 

(f) The Contractor shall provide services and systems for Agency 
access to archived data. Processes and procedures for access to 
archived data shall be described. 

5.2.9 Audit (DR 5.09) 

The Contractor shall provide for an annual independent audit of the RFC 
system to validate accuracy of all systems processing, cash management, 
and Agency settlement. Audit shall be conducted in accordance with 
generally accepted auditing standards by an independent auditing firm 
acceptable to the Agencies. Books, records, document, and other evidence 
directly pertinent to performance under this Contract shall: 

• Be maintained for a minimum of six (6) years 

• Kept in accordance with generally accepted accounting principles 

• Made available upon request for examination 

6.11-5.3 Performance Requirements 

(a) The batch interface shall have a minimum 99% availability 24 hours a day, 7 days 
a week, per the availability formula contained in Section 6.III-1.5.2. 



(b) The on-line interface shall have a minimum 99% availability 24 hours a day, 7 
days a week, per the availability formula contained in Section 6 III-1.5.2. 

(c) Revenue shall be reconciled and settled with 100% accuracy. 

(d) Financial settlement shall be the next business day after transactions are uploaded 
to the clearinghouse system. 

(e) Daily reports shall be available by 8 a.m. Pacific time the next business day. 

(f) Monthly reports shall be available by the sixth (6 th ) business day of the following 
month. 

(g) Data extracts for the Agencies shall be available the next business day. 

(h) At a minimum, data shall be uploaded and downloaded every 24 hours. 

(i) Card, application and function blocks, option changes, and revalue information 
shall be downloaded to the Data Acquisition System within twelve (12) hours and 
to the Revalue Network within twenty four (24) hours of recording by the 
clearinghouse system. 
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6.11-6 MARKETING PLAN 

This Section has been deleted in its entirety. The 
Agencies will be responsible for marketing. 
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6.11- 7 Financial Management 

6.11- 7.1 Financial Management Description 

The Contractor shall provide services necessary for the financial management of 
revenues accrued through RFCS operations (DR 6) including: 

• Management of funds transfers between Agency accounts. 

• Management of funds transfers between third party revalue points and Agency 
accounts. 

• Management of fees approved or implemented by the Agencies. 

• Providing invoicing information in support of Institutional Program 
Management. 

All financial management practices shall be per the direction of or shall be approved 
by the Agencies. 

6.11- 7.2 Functional Requirements 

7.2.1 Cash Management (DR 6.01) 

(a) The Contractor shall be responsible for management and 
accounting for revenue from transactions. 

(b) The Contractor shall manage funds between Agency-designated 
accounts, and between third party accounts and Agency-designated 
accounts. 

(c) The Contractor shall establish secure file transfer processes which 
comply with settlement and management practices as directed by 
the Agencies. 

(d) Revenue transfers from third party accounts shall be deposited into 
designated Agency accounts. 

(e) The RFCS shall support the acceptance of payment in the 
following forms: 

i. Credit card 

ii. Debit card or direct bank debit 

iii. Cash sales 

iv. Checks sales 

v. Vouchers 

vi. ACH or direct deposit 
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(f) The Contractor shall prepare a management plan which identifies 
risk and risk management strategies for non-sufficient funds (NSF) 
revalue transactions (CDRL 6) related to check handling and other 
payment forms. 

(g) All payments shall be on a cash basis, distributed at the time of 
funds receipt. 

(h) All add value payments shall be reconciled against supporting 
revalue transactions, regardless of whether payment occurs at the 
time of or subsequent to the revalue transaction. 

(i) The Contractor shall reconcile all payments in the system against 
receipts and settlements. 

(j) The Contractor shall provide reports with the data to support all 
accounting functions as required by the Fiscal Agent. 

(k) The Contractor shall implement procedures to ensure security and 
integrity of system accounts and daily receipts, such as dual person 
control points, lock boxes, independent verification of deposits, 
and other common financial controls. 

7.2.2 Fee Management (DR 6.02) 

(a) The Contractor shall, under the direction of and subject to approval 
by the Agencies, track, account for, collect or pay, audit, and settle 
fees associated with Contractor’s RFCS servicing, including: 

i. Credit card merchant fees 

ii. Debit card interchange fees 

iii. Retailer sales commissions 

iv. ACF1 item fees 

v. Banking fees (check handling, lockbox, NSF, etc.) 

vi. Card fees and refunds (per Contract Administrator direction 
and agreement) 

(b) The Contractor shall provide general accounting processes to 
manage all fee receipt and payments and shall provide daily 
reconciliation of fees paid or collected as a part of cash entering 
and exiting the system. 

(c) The Contractor shall provide adequate management and control 
procedures related to all fee receipts and disbursements. 
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7.2.3 Merchant of Record (DR 6.03) 


(a) A designated Agency will act as merchant of record. The 
Contractor shall provide merchant of record services on behalf of 
that agency for credit card and debit card conducted by 
Contractor. 

(b) The Contractor shall be responsible for operation and management 
of all related merchant of record functions for transactions 
conducted by the Contractor including: 

i. Charge backs 

ii. Denials and reversals 

iii. Cancellations and adjustments 

iv. Audit and control 

v. Transaction settlement and cash reconciliation 

vi. Fees 

vii. Dispute handling and resolution 

viii. Fraud control 

7.2.4 Institutional Program Management (include in DR 2) 

(a) The Contractor shall provide services for invoicing and collection 
of revenues per the terms of the individual institutional payment 
arrangements between one or more Agencies and the individual 
institution. 

(b) The Contractor shall provide standard accounting records and 
functions (accounts payable, accounts receivable, invoicing, 
general ledger, payments processing, accounts aging) for 
management of each of these programs. 

6.11-7.3 Performance Requirements 

(a) The Contractor shall comply with Washington State Office of the State 
Treasurer/Office of Financial Management and local agency financial 
management requirements. 

(b) The Contractor shall mitigate risk on funds management. 

(c) The Contractor shall maintain receivables at less than forty-five (45) days 
from the receivable due date. 

(d) The Contractor shall reconcile revenue daily (7 days a week). 
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6.11- 8 Network Management 

6.11- 8.1 Network Management Description 

The RFCS program inherently will require a distribution of functions to many 
locations which will be linked together through a telecommunications infrastructure. 
Information shall flow between the points of service, the revalue network, the data 
acquisition system and fare transaction processors, the clearinghouse system and the 
various Agencies back office systems. 

The Agencies will provide local communications in the Central Puget Sound Region 
to all Agency facilities using Government data networks and/or local commercial 
communications service providers. 

The Contractor shall provide communications to services and facilities outside the 
Central Puget Sound Region (e.g. remote clearinghouse, second-tier customer service 
center, repair facility, etc.), the retail communications network, and (if required) 
communications to institutions (DR 7). 

6.11- 8.2 Functional Requirements 

8.2.1 Agency-Supplied Networks 

(a) The Agencies will provide and maintain local communications to 
transit bases, ferry and rail terminals, Agency headquarters, and 
other Agency locations in the Central Puget Sound Region to meet 
communications requirements specified by the Contractor. 
Communications will be provided between the following RFCS 
nodes at Agency facilities: 

i. Operating Base WDOLS Access 

ii. Data Acquisition Computers (DACs) 

iii. Back Office Computer (BOC) Server 

iv. BOC Client 

v. SNMP Collection Server (if applicable) 

vi. WSF Gate Adaption Kit (GAK) Fare Processor 

vii. Stand-Alone/On-line Fare Transaction Processors (FTPs) 

viii. Sound Transit CDCS 

ix. Sound Transit TVMs 

x. Customer Service Terminals 

xi. Point of Sale (POS) Server (if applicable) 

xii. Agency Back Office Systems 




(b) The Agencies will provide local communications links to credit 
card, debit card and ACH networks for endpoints where the 
Agencies are the merchant of record, except for those transactions 
conducted via the RFCS website for which the Contractor is 
responsible for providing said communication links. 

(c) Local communications facilities shall consist of existing 
Government and/or commercial carrier networks. The Agencies 
will be responsible for providing the necessary equipment and 
network management, authentication and access control for their 
local communication networks. 

(d) The Contractor shall be responsible for fault detection and 
performance monitoring of Agency provided communications 
network Equipment to which the Contractor has been given 
specific access privileges and monitoring capabilities based on the 
roles and responsibilities of the Contractor and the Agencies 
described in the FDR documents. If the Contractor is denied direct 
access to agency supplied network equipment, then the Contractor 
may be forwarded SNMP information via an agency designated 
SNMP collection server. The ability of the Contractor to perform 
the detection and monitoring activities on Agency-supplied 
equipment will be dependent, in this case, on the type of SNMP 
information provided. 

(e) The Contractor shall identify network capacity, security and 
performance requirements required for RFCS operation. 

8.2.2 Contractor Supplied Networks 

(a) The Contractor shall provide communications to support all system 
interfaces not included in the Agency supplied network. At a 
minimum, the network shall provide for the interconnection of the 
following: 

i. Local devices connected through the Agency supplied 
network. 

ii. Clearinghouse system 

iii. Contractor provided call and repair centers 

iv. Debit, credit and ACH networks 

v. Revalue network 

vi. Institutional Programs (if required) 

vii. Internet 

(b) The Contractor shall provide a network configuration that shall 
provide adequate availability and capacity to meet the demands of 



each individual interface and end point. Such communications 
may include, subject to each Agency’s approval which shall not be 
unreasonably denied, on-demand (dial) services, radio frequency, 
leased line, frame relay, packet switched, Internet access, satellite, 
or any other transport mode according to the Contractor’s selected 
solution. 

(c) The provision and management of network components will be 
subject to individual Agency maintenance practices. 

(d) The network shall include backup communications in the event of 
a failure of the primary link. 

8.2.3 Network Management (DR 7.01) 

(a) The Contractor shall provide network management services 
necessary to monitor and support the network infrastructure (both 
Agency and Contractor supplied) to ensure continued high 
availability and transaction throughput. The Contractor shall 
notify the Agencies of any network conditions or events that 
appear to affect RFCS operations including but not limited to data 
throughput. 

(b) Monitoring and management of each Agency’s network shall be 
per Agency policy and systems. 

(c) In the event that Agency firewalls or other protections prevent 
direct monitoring of devices connected to the Agency network, the 
network management system shall accept fault detection or alarms 
by Agency monitoring systems. 

(d) The Contractor shall notify the Agencies or their designates in the 
event of fault detection or failure of the Agency supplied network 
to meet performance requirements. 

(e) The Contractor shall provide a network backup and disaster 
recovery plan, procedures and systems (CDRL 5). 

8.2.4 Data and Operations Management (DR 7.02) 

(a) The Contractor shall provide services and systems for: 

i. The regular backup of all data 

ii. Off-site archiving 

iii. Reporting 

iv. Data recovery 



(b) The Contractor shall identify in Design Review documentation 

(DR 7.02): 

i. Points of risk, failure or uncertainty in the communications 
network. 

ii. Procedures for maintaining the integrity of all data. 

iii. Bandwidth, availability and other requirements for the 
Agency supplied communications network to meet the 
performance requirements of 6.II-8.3. 

6.11-8.3 Performance Requirements 

(a) The communications network shall have a minimum 99% availability 24 
hours a day, 7 days a week, per the availability formula contained in Section 
6.III-1.5.2. 

(b) On-line transaction response times shall be less than two (2) seconds from the 
request being sent to the end point plus time required for credit and debit card 
authorization (if applicable). 

(c) Network capacity shall be provided so that all daily upload and download 
activity is completed within one (1) hour. 

(d) The Contractor shall not be responsible for failure to meet the above 
performance requirements to the extent the failure was caused by the Agency- 
supplied network. 
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6.11- 9 Revalue Network Support Services 

RFCS Contractor shall provide equipment and support services for a geographically 
comprehensive retail revalue network as part of this Contract (DR 8). This is in 
supplemental to the core fare card revaluing subsystems and options described 
elsewhere in this RFR 

The supplemental revalue network is expected to include between 100 and 200 retail 
locations throughout the region. It shall be the Contractor’s responsibility to provide 
equipment for and maintain the supplemental revalue network. 

6.11- 9.1 General Requirements 

(a) The Contractor shall be responsible for providing all required hardware, 
software, communications, maintenance and technical support for the revalue 
network (DR 8.01). 

(b) The Agencies shall maintain and manage contractual agreements with retail 
outlets, and shall be responsible for the establishment of the commission 
structure. These commissions will be handled by the Agencies outside of the 
Clearinghouse. 

(c) The Contractor shall provide hardware, software, communications and 
support, and shall be responsible for equipment installation and maintenance 
at Agency designated retail outlets. 

(d) Contractor shall cooperate with and assist the Agencies in establishing 
additional revalue services, and shall be reimbursed for such services under 
separate agreement. This may include special arrangements for institutional 
programs. 

(e) All devices and/or locations should be identified by the RFCS logo and 
program name. 

6.11- 9.2 Functional Requirements 

The revalue network and support services shall meet the following functional 
requirements: 

(a) The revalue network as a whole shall cover all types of RFCS revalue 
functions and fare categories, including passes, multi-rides and stored value. 

(b) The revalue network shall permit customers to pay with multiple forms of 
payment. Not all devices are required to support all types of payment, but the 
revalue network as a whole shall support payment by cash, credit, debit, 
electronic purse, and employer program electronic coupon. 
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(c) Some or all of the revalue network shall permit customers to check the 
remaining balance on their cards and to view transaction history up to the last 
10 transactions. 

(d) The revalue network system and data shall be auditable by independent 
auditors should the Contractor and/or the Agencies deem an audit necessary. 

(e) The Contractor shall train Agency staff in the operation of retail outlet revalue 
devices. Agency staff will be responsible for training retail outlet staff. 

6.11-9.3 Performance Requirements 

The Contractor shall provide equipment, installation and support for a revalue 
network throughout the Region where consumers can load value onto RFCS 
cards. Such a network shall be dispersed geographically consistent with the Agencies 
overall distribution strategy and retail outlet locations. 

(a) The Contractor shall provide details of revalue network support services in 
their Revalue Network and Support Services Plan (CDRL 7). 

(b) The Revalue Network and Support Services Plan shall include quantified 
performance standards and measurement methodology, and shall be 
developed in cooperation with the Contract Administrator and designated 
Agency customer service staff. 

(c) Minimum performance standards shall include: 

i. Repair or replacement of revalue network devices within two (2) 
working days of fault notification or detection. 

ii. Ability to operate in an off-line mode. 

iii. For dial-up connections, no more than three retries before a successful 
connection. 

(d) The revalue network shall provide revalue options for, and be designed for 
ease of use by, various transit customer groups and markets. Criteria to be 
considered include: 

i. Providing access and payment options for banked and unbanked 
customers alike 

ii. ADA requirements accommodation 

iii. Using new technologies to increase revalue options 

iv. Designing devices for ease of use using modern industrial design 
practices, and providing clear instructions for use 

v. Providing maximum availability over a 24 hour period 

vi. Being cost effective for Agencies, retail outlets and customers 
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Maintenance and Technical Support Services 


Division II 


6.11- 10 Maintenance and Technical Support Services 

6.11- 10.1 Maintenance and Technical Support Services 

(a) The Contractor shall provide maintenance services as described in Section 3.1- 

58, RFC System Warranty and Post-Warranty Maintenance, including: 

i. Depot Maintenance 

ii. On-Site Maintenance 

iii. Software Maintenance 

(b) Contractor and Agency responsibilities shall be described in a Maintenance 

Plan (CDRL 8). 

(c) The Contractor shall provide monthly Maintenance Reports including: 

i. System Wide Spares Inventory Report (CDRL 9) 

ii. Fault Tracking and Maintenance Performance Reports (CDRL 10) 

(d) The Contractor shall provide Agency Technical Support Services as described 

in 6.II-10.2. 

6.11- 10.2 Agency Technical Support Services 

10.2.1 Technical Support Services 

Contractor shall provide technical support over the phone to Agencies. 

(a) Technical support shall cover all RFCS software, hardware, and 
systems and operational processes necessary for Agency operation 
of the system. 

(b) All technical support personnel shall be fully qualified to perform 
such support functions; the Contract Administrator reserves the 
right to request replacement of personnel deemed unqualified or 
whose performance deemed unsatisfactory for any reason. 

(c) The Contractor shall maintain an on-line knowledge base of 
maintenance events, problems and resolution. 




10.2.2 Agency Phone Support Service Levels 

Phone support shall be provided by “live” personnel, or some combination 
of “live” personnel and automated response. 

(a) Maintenance and Agency phone service support levels shall be 
subject to Contract Administrator approval and shall include the 
following minimum requirements: 


(i) Hours of operations: 

24 hours per day, 7 days per week 

(ii) Calls connected within: 

4 rings 

(iii) Time in phone queue: 

90% of calls within 20 seconds of 
connection 

100% of calls within 2 minutes of 
connection 

(iv) Abandoned call rate: 

Less than 4% 


(b) Contractor shall develop service procedures and service personnel 
requirements (CDRL 11). 

(c) Contractor shall maintain detailed statistics of support service 
efficiency and operation and provide a methodology for measuring 
performance (CDRL 11). A Support Service Statistics report shall 
be provided to the Contract Administrator monthly (included in 
CDRL 12). 

Performance measurement methodology is subject to Contract Administrator review 
and approval. 







System Implementation 


Division II 


6.11-11 System Implementation 

The implementation of the RFCS will occur in two Phases. Phase I will culminate with 
Beta Test Acceptance, and Phase II will culminate with Full System Acceptance. In 
addition, the Agencies will use the definitions for Project Schedule Acceptance, Final 
Design Review Acceptance, Beta Test Readiness Acceptance, Beta Test Acceptance, and 
Full System Acceptance when determining completion for payment purposes. Definitions 
of these are as follows: 

(a) Phase I: Design and Implementation through Beta Testing. The purpose of Phase I is to 
design the entire RFC system and then test (end-to-end) full system functionality of all 
components of all systems in revenue service with a limited number of cardholders and 
limited equipment. Beta Testing is further described in Section 11.4.6. 

(b) Project Schedule Acceptance: Project Schedule Acceptance will occur upon approval 
by the Contract Administrator of the Baseline Project Schedule. 

(c) Final Design Review Acceptance: Final Design Review Acceptance will occur upon 
approval by the Contract Administrator of the Final Design Review (Sections 6.II- 
11.2.2.3 and 6.II-11.2.3). 

(d) Beta Test Readiness Acceptance: Beta Test Readiness Acceptance will occur upon 
approval by the Contract Administrator of the Certification of Beta Test Readiness 
(Section 6.II-11.4.6.6). 

(e) Beta Test Acceptance: Beta Test Acceptance will occur upon approval of the 
following items by the Contract Administrator: 

i. Completion of all design, development, installation, integration, test, and 
documentation requirements for Phase I 

ii. Completion of all Engineering and Design requirements for Phase I 
described in Section 11.2 

iii. Completion of all Installation requirements for Phase I described in Section 
11.3 

iv. Completion of all Testing requirements for Phase I described in Section 11.4 

v. Completion of all items for Phase I on the Contract Document Requirements 
List (CDRL) in Section 11.6 

vi. Completion of all Training requirements for Phase I described in Section 12 

(f) Phase II: Full RFCS Rollout. The Contractor shall proceed with Phase II upon Beta 
Test Acceptance and approval from the Contract Administrator. Phase II shall include 
the following activities: 

i. Design and test of any system modifications as a result of the Beta Test 

ii. Installation of all RFCS equipment region wide 
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iii. Distribution of RFCS cards region wide 

iv. Expanding services until required levels have been achieved and maintained 
for a specified period of time 

(g) Full System Acceptance: Full System Acceptance of the RFCS will occur upon 
approval of the following items by the Contract Administrator: 

i. Completion of all design, development, installation, integration, test, and 
documentation requirements for Phase II 

ii. Completion of all Engineering and Design requirements for Phase II 
described in Section 11.2 

iii. Completion acceptance of all Installation requirements for Phase II 
described in Section 11.3 

iv. Completion of all Testing requirements for Phase II described in Section 
11.4 

v. Completion of all items for Phase II on the Contract Document 
Requirements List (CDRL) in Section 11.6 

vi. Completion of all Training requirements for Phase II described in Section 12 

vii. Completion of all outstanding work and deliverables 

The Contractor shall be fully responsible for implementation of the system. This section 
defines the requirements for the implementation of the RFC system, as follows: 

(a) Implementation planning criteria 

(b) System engineering and design requirements 

(c) System/equipment installation requirements 

(d) System/equipment testing requirements 

(e) Progress and performance monitoring process 

6.11-11.1 Implementation Planning Criteria 

This section identifies the requirements for the development of the implementation 
approach for the RFCS. The following items are presented: 

(a) Regional implementation criteria 

(b) Agency specific criteria 

(c) Regional preference 

(d) A schedule of implementation milestones 

(e) Requirements for the development of an Implementation Plan 



(f) Requirements to conduct special demonstration programs 

11.1.1 Regional Implementation Criteria 

The Contractor shall design the RFCS rollout strategy to meet the following 
objectives and criteria: 

(a) The RFCS shall be based on the introduction of a contactless-only card 
to support the RFCS application. All devices in the system that 
communicate with the card (including retail revalue devices) shall do so 
via the contactless interface. 

(b) Provide immediate customer value 

(c) Minimize revenue exposure 

(d) Minimize negative publicity in the event of system or equipment failure 

(e) Minimize operational disruptions 

(f) Minimize implementation cost 

(g) Maximize efficiency and speed of implementation 

(h) Maximize coordination of services offered by interfacing Agencies 

(i) Complete Phase II - Full RFCS Rollout. Date to be determined. 

(j) Complete Agency training necessary to operate, support, and maintain 
the Phase I and Phase II system prior to the RFC system going live in 
Phase I and Phase II, respectively. 

The implementation strategy for the Phase I and Phase II rollout shall be 
developed in concert with the Contract Administrator and these criteria and 
documented in the Implementation Plan (CDRL 13) described in Section 
11.1.5. 



11.1.2 Agency Specific Implementation Criteria 


The implementation of RFC S at each of the participating Agency sites will vary 
based on the operating environment for each Agency (i.e. Bus, Rail and Ferry), 
the fare structures supported by each Agency (i.e. flat fare, distance based/zone 
based fare, route based fare), and the regional fare policy developed. Detailed 
implementation requirements for each Agency’s systems required and 
quantities, fare structures to be supported and fare tables, infrastructure profile 
and installation requirements will be provided during system design. Estimated 
equipment quantities are documented in Appendix A, “Estimated Agency 
Equipment Quantities”. Equipment quantities will be finalized at the time of 
order. 

The Contractor shall work directly with each Agency to further define 
requirements for Beta Test and Full Rollout, including equipment installation, 
and card introduction/distribution. In cooperation with each Agency, the 
Contractor shall develop detailed rollout requirements for each Agency as 
follows: 

(a) The Contractor shall visit the facilities of each Agency to develop a 
complete understanding for the specific implementation requirements at 
each Agency. 

(b) The Contractor shall work with individual Agencies to finalize the 
details of their implementation. This shall include reaching final 
agreement on the seating of all equipment to be installed at that 
Agency’s facilities or on their vehicles. 

(c) Such agreement shall be formally approved by each Agency and by the 
Contract Administrator. 

A list of estimated Beta test equipment quantities is contained in Appendix A. 

11.1.2.1 Community Transit 

The following requirements shall apply to implementation of the RFCS 
(including Beta Test equipment, unless otherwise indicated) at Community 
Transit (CT): 

(a) The Beta Test shall consist of equipment installed at two bases, to be 
specified by the Contract Administrator, and must include CT’s CSO to 
test the integration of the CT point of sale terminal with the new system. 

(b) Equipment rollout shall occur by base. 

(c) On-site installation of equipment shall occur only on weekends 
(Saturdays and Sundays) at times to be coordinated with CT. 



(d) All equipment installation shall be coordinated with CT personnel to 
permit CT personnel to observe/assist with installation activities. 

(e) System start-up shall not occur on the day of a seasonal service schedule 
change (mid February and mid September). 

11.1.2.2 Everett Transit 

The following requirements shall apply to implementation of the RFCS 

(including Beta Test equipment, unless otherwise indicated) at Everett Transit: 

(a) Installation of all equipment shall take place at Everett Station. 

(b) System implementation shall be coordinated with that of Community 
Transit implementation at Mukilteo. 

(c) No system start-up shall occur on the day of a seasonal service schedule 
change. 

11.1.2.3 King County Metro 

The following requirements shall apply to implementation of the RFCS 

(including Beta Test equipment, unless otherwise indicated) at King County 

Metro: 

(a) The Beta Test shall consist of equipment installed at only one base, to be 
specified by the Contract Administrator, and must include at least one 
CSO to test the integration of the KCM point of sale terminal with the 
new system. 

(b) On-site installation of equipment shall occur during the days and times 
as directed by KCM, and may occur on weekdays and/or weekends 
(Saturdays and Sundays). 

(c) No system start-up shall occur on the day of a seasonal service schedule 
change which usually occurs on the first Saturday in February, last 
Saturday in May, and the third Saturday in September. 

(d) King County Metro will replace their existing mobile data terminal 
(MDT) with the driver display unit (DDU) and radio control unit (RCU) 
supplied under this contract. 

(e) The driver display unit and radio control unit must be operational before 
the on-board equipment is installed. Not later than ten (10) days after 
FDR NAC, the Contractor shall deliver for the Contract Administrator’s 
approval a DDU/RCU Integration Test Plan. As stated in the Project 
Schedule, the Contractor shall successfully complete, on at least two 



buses in Seattle with King County representatives present, the agreed- 
upon DDU/RCU Integration Test and demonstrate that the DDU and 
RCU will provide the required functionality at a satisfactory level for use 
in County revenue service. Said DDU/RCU Integration Test shall be 
performed, and the report of same provided to King County, in 
accordance with Section 6.II-11.4.8. 

(f) Implementation of the RFCS in King County shall be coordinated with 
the work of other contractors and the implementation of other on-board 
systems. Three devices, the Driver Display Unit (DDU - Section 6.III-6) 
the Radio Control Unit (RCU - Section 6.8.3) and the WDOLS (Section 
6.III-7) are integral to King County’s on-board systems projects. These 
timelines are to support other projects and do not supersede equipment 
delivery requirements of the RFCS implementation set forth in the 
Contract Section 6.II-11 System Implementation. And the approved 
Project Schedule. These and other related devices shall be delivered as 
described below. 

i. By March 1, 2006, five (5) production (or pre-production, if 
production equipment not yet available) DDUs shall be delivered 
to King County. These will be used by King County and 
designated contractors to develop other on-board system devices 
and applications. 

ii. The DDU shall have the production hardware, operating system, 
user interfaces, and data interfaces, as well as the core application 
software required to operate the device, program and operate the 
keys and display, and create, send and receive messages to other 
devices. Full RCU-related functionality and the “home” screen 
will be provided. Full functionality of RFCS-specific application 
software will be provided to the extent then available 

iii. DDU software and documentation shall be provided such that 
application and interface development can proceed on the DDU 
and other on-board devices (by King County or designated 
contractors). 

iv. By March 1, 2006, five (5) production (or pre-production, if 
production equipment not yet available) RCUs shall be delivered 
to King County. These RCUs shall have the production hardware, 
operating system, and data interfaces required to operate the 
devices. Final documentation shall be delivered. 

v. By March 1, 2006, five (5) production Wireless Data On-Off 
Load Systems (WDOLS - Section 6.III-7) on-board and bus 
antenna devices and one (1) production (or pre-production, if 
production equipment not yet available) Data Collection Systems 
(DACS - Section 6.III-12) shall be delivered to King County. 
These will be used to develop and test data transfer from the 
vehicle to the DACS. Both devices shall be supplied with the 



hardware, software and documentation required to conduct this 
development. Full functionality of RFCS and King County- 
specific functionality and application software will be provided to 
the extent then-available. 

vi. To the extent pre-production equipment must be provided to meet 
the above due dates, the Contractor shall provide production 
equipment as soon thereafter as it becomes available. 

(g) As stated in the Project Schedule, final production DDUs and RCUs 

shall be delivered in quantities to support the RFCS Beta test Estimated 
quantities for both tests are included in Appendix A. 

11.1.2.4 Pierce Transit 

The following requirements shall apply to implementation of the RFCS 
(including Beta Test equipment, unless otherwise indicated) at Pierce Transit: 

(a) The Beta Test shall consist of equipment installed at only one base, to be 
specified by the Contract Administrator, and must include at least one 
CST. 

(b) Equipment rollout shall occur by base. 

(c) Installation of equipment depends on staging process selected. 

(d) No system start-up shall occur on the day of tri-annual service change 
(dates to be provided by PT). 

11.1.2.5 Sound Transit 

11.1.2.5.1 Background 

Sound Transit will operate bus (Regional Express), commuter rail (Sounder) and 
light rail (Link) services. Fareboxes for Regional Express buses have been 
procured through a separate contract. Sound Transit has also installed Scheldt & 
Bachmann ticket vending machines, ticket office machines, and a central data 
collection system for Sounder. Fare collection equipment for Link light rail has 
not yet been selected. 

11.1.2.5.2 Criteria 

The installation of all equipment shall be coordinated with Sound Transit. 

(a) The RFCS contractor shall coordinate with Sound Transit’s rail fare 

collection system provider for the implementation of RFCS functionality 
at rail facilities as defined in Section 6.III-13.2.2.7. 



(b) Sound Transit buses are assigned to facilities owned by existing transit 
Agencies. Therefore, the installation and start-up of on board equipment 
for Sound Transit buses shall be coordinated with the RFCS 
implementation at the Agency bases to which the corresponding vehicles 
are assigned. 

(c) Beta Test on Sound Transit shall include Sounder Service between 
Tacoma and Seattle, and Regional Express Tacoma-Seattle service. 

(d) Beta Test shall include TVM modifications and customer service 
facilities at the Tacoma Dome and King Street. 

(e) Beta Test may include Pierce Transit services at the Tacoma Dome. 

(f) Installation procedures and schedule for supplying and installing 
equipment on Sound Transit coaches operated by King County Metro 
shall be per Section 6.II-11.1.2.3. 

11.1.2.6 Kitsap Transit 

The following requirements shall apply to implementation of the RFCS 

(including Beta Test equipment, unless otherwise indicated) at Kitsap Transit: 

(a) The Beta Test shall operate on Kitsap Transit commuter bus service, and 
shall include one Customer Service Terminal. 

(b) System implementation shall be coordinated with Washington State 
Ferries. 

(c) No on-board equipment installation shall take place during commute 
hours. 

11.1.2.7 Washington State Ferries 

The following requirements shall apply to implementation of the RFCS 

(including Beta Test equipment) at Washington State Ferries: 

(a) The Beta Test shall consist of equipment installed at one terminal and 
possibly two routes out of that terminal (to be specified by WSF at 
Conceptual Design Review). 

(b) The Beta Test may include one Customer Service Terminal CST for 
WSF. 

(c) Equipment rollout shall occur by terminal, by route. 

(d) On-site installation of equipment shall occur during the days and times 
as directed by Washington State Ferries. 



(e) No system start-up shall occur on the day of a seasonal fare or schedule 
change. These occur three times a year. 

(f) The interface between the RFCS and WSF Electronic Fare System shall 
be included in the Beta Test. 

(g) GAK Design Revision work shall include Design Specifications as 
delivery for FDR NAC: 

1. Completion of all work associated with the provision of DR112 up 
to and including the FDR approval. 

(h) GAK Design Integration and Testing shall include the following: 

1. Completion of the Detailed interface (Protocol modifications 
required to be made to the baseline communications protocol as 
supplied as a separate document from DR112) by ERG during the 
period leading up to FDR submission of DR112b. 

2. Implementation of all software interface changes. 

3. Implementation of any functional changes required during the initial 
Final Design Review process to the GAK Gate & POS and BOC 
applications software to fulfill the functional solution as described in 
DR112. 

4. Provision of integration support required ensuring the successful 
technology integration of the EFS and ERG solutions. 

5. Testing of all ERG supplied software requiring adequate support by 
the EFS solution provided in regard to joint integration and testing. 

6. Provision of any ERG supplied Technology required for the 
development of the POS / Fare Gate Solution both by ERG and the 
EFS Solution Provider (as detailed within the Integration section of 
DR112). 

7. Provision of implementation (Installation, commissioning) support 
services. 

(i) The scope of work does not include any post Beta design review or 
technology update other than rebuild of software based on RFC system 
wide changes in association with Card format, Business Rule 
Implementation, ETser Data (UD)/Configuration Data (CD) changes due 
to Data Acquisition Computer (DAC)/ Back Office Client Application 
(BOC) changes, and Clearing House (CHS) agreed changes. 



11.1.3 Regional Preference 


The preferred regional implementation strategy for Phase II rollout is to install 
all equipment system-wide following completion and acceptance of the Beta 
Test. Within the installation process, all on board vehicle equipment and data 
acquisition computers would be installed by operating base. 

On completion of system wide installation, the system rollout would occur by 
customer type i.e. agency personnel, institutional accounts, campus and finally 
general public. Card distribution will occur in a controlled and managed process 
where cards will be released based on the confidence in and reliability of the 
system. All cards will be fully functional when released for use. The future 
implementation plan must address future card use on services that are not yet 
operational (i.e. Sound Transit Link). 

11.1.4 Implementation Milestone Schedule 

The Contractor shall use the milestones listed in Figures II-ll.l and II-11.2 as 
the basis for developing the project schedule. 



Figure 11-11.1 

System Design, Engineering and Testing Milestones 


MILESTONE 

COMPLETION 

CRITERIA 

Phase I Notice to Proceed 




Phase I Design, Engineering and Testing 


Submit Project Schedule and Quality 
Assurance and Control Plan 


Project Schedule Acceptance 

All items defined in Section 
6.II-11 (b) 

Complete Conceptual Design Review 

All items defined in Section 
11.2.2.1 

Complete Final Design Review and 
Establish Design Baseline for 
Hardware 

All items defined in Section 
11.2.2.3 and 11.2.3, new 
Figure II-11.2.2.2 and new 
Figure II-11.2.2.3 for 
Hardware Group 

Complete Final Design Review 
and Establish Design Baseline for 

Groups 1,2, and 3 

All items defined in Section 
11.2.2.3 and 11.2.3, and new 
Figure II-11.2.3 for Groups 
1,2, and 3 

Final Design Review Acceptance 

All items defined in Section 
6.II-11 (c) 

Complete Factory Acceptance Testing 

FAT elements defined in 
Section 11.4.2 for each type of 
equipment 

Complete System Integration Testing 

All items defined in Section 
11.4.3 

Deliver Beta Test Systems and 

Equipment, O&M, Software, and 
Training Manuals and software 
documentation 

All items defined on Price 
Schedule 

Complete Installation Inspection of 
Equipment to be Beta Tested 

All items defined in Section 
11.3.2 

Beta Test Readiness Acceptance 

All items defined in Section 
6.II-11 (d) 

Complete Installation Testing and 

System Commissioning 

All items defined in Section 
11.4.4 and 11.4.5 

Complete Agency Training 

All applicable training as 
defined in Section 12.2 

Begin Beta Test 

n/a 

Complete Beta Test (Functional 
Acceptance) 

All items presented in Section 
11.4.6. 

Beta Test Acceptance 

All items defined in Section 
6.II-11 (e) 



Phase I Complete 




























Figure 11-11.2 
Full Rollout Milestones 


MILESTONE 

COMPLETION 

CRITERIA 

Phase II Notice to Proceed 




Phase II Design and Testing 


Complete Final Design Review 

Revised QA/QC Plan and 
revised/updated versions of all 
items described in Section 
11.2.2.3 

Complete Factory Acceptance Testing 
for Modified Systems and 
Equipment 

FAT elements defined in 
Section 11.4.1 

Complete System Integration Testing for 
Modified Systems and Equipment 

All items defined in Section 
11.4.3 



Phase II Installation and Testing 


Deliver and Install Full Rollout 
equipment and software 

All items listed on Price 
Schedule 

Deliver Full Rollout Configuration 

O&M, Software, and Training 
Manuals and software 
documentation 

All documents listed in Figure 
II-11.4 

Complete Installation Testing 

All items defined in Section 
11.4.3 

Complete System Commissioning 

All items defined in Section 
11.4.4 

Complete Operator Training 

All applicable training as 
defined in Section 12.2 

Begin Settling-In Period 

All items presented in Section 
11.4.7.1. 

Complete Acceptance Testing of RFCS 
Systems and Equipment 

Upon successful completion 
Acceptance Testing according 
Section 11.4.7 

Full System Acceptance 

All items defined in Section 
6.H-H(g) 



Begin RFCS Operations and Management 
Contract 

System Acceptance 



Begin RFCS Warranty Period 

System Acceptance 





























11.1.5 Implementation Plan 


The objective of the Implementation Plan is to provide criteria for design 

review, development testing and rolling out RFCS. 

(a) The Contractor shall develop, for Contract Administrator review and 
approval, the Implementation Plan (CDRL 13) defining criteria which 
must be undertaken for the full rollout of the RFCS, how these actions 
will be implemented, and the schedule for completion. 

(b) The Implementation Plan shall identify schedule drivers and assign 
responsibility for key components of the system. 

(c) Key components shall include functional, operational, and technical 
requirements, schedule coordination and systems integration criteria. 

(d) The Implementation Plan shall separately identify and define, at a 
minimum, the following criteria for the Beta Test and Full Rollout. 

i. Agencies and facilities/locations designated for each stage of the 
implementation program. 

ii. System architecture requirements including required 
functionality, methods of data transfer, audit and record-keeping 
requirements for each Agency, and establishment and operation 
of the Clearinghouse. 

iii. Equipment requirements for each Agency including hardware, 
software, and network needs. Equipment requirements shall be 
summarized by implementation stage. Agency and location when 
applicable. 

iv. Schedule for equipment design, development and prototype, 
testing, production, and installation tasks. Critical paths and 
dependencies shall be identified for each stage. 

v. Roles and responsibilities of the participating Agencies, outside 
vendors, retail distributors and other parties involved in the 
program. 

(e) The Implementation Plan shall incorporate, and be consistent with, the 
plans governing specific sets of activities or project activities such as 
design, testing, installation, and operations. 

(f) The Implementation Plan shall be based on concurrent installation work 
occurring across all Agencies. Installation work shall be per Section 
6.II-11.3.1. 

(g) The Implementation Plan is subject to the review and approval of the 
Contract Administrator. This Implementation Plan shall constitute the 



formal schedule commitments of the Contractor and shall be used to 
monitor and control the project. 

11.1.5.1 Revisions 

(a) The Plan shall be revised to reflect planned or unplanned events 
throughout the implementation process. 

(b) Two planned events that shall require formal revisions of the Plan are: 

i. Finalization of the RFCS design, to reflect the impacts of any 
changes in the system from the original proposal. 

ii. Evaluation of the Beta Test, to reflect the impacts of any 
decisions taken as a result of the Beta Test experience. 

(c) The Implementation Plan shall be updated every month throughout the 
system rollout, or whenever there are major changes during the 
implementation process. 

(d) All revisions to the Implementation Plan are subject to approval by the 
Contract Administrator. 

11.1.6 Special Programs 

The Contractor shall provide equipment and services for Special Programs as 

described below. 

11.1.6.1 Vanpool Demonstration 

The Vanpool Demonstration shall consist of the following: 

1. Equipping a minimum of 10 vanpools with Portable FTPs. These shall 
not include vanpools that use WSF services. A decision to proceed with 
the vanpool demonstration and final schedule will be determined at PDR 
(CDRL 2). 

2. Providing back office reporting and integration to allow customers with 
RFCS cards to use vanpools that are not equipped with PFTPs. This 
functionality shall be implemented as part of Phase I. 

Vanpools Equipped with PFTPs: 

(a) PFTPs shall meet the requirements for a full-function PFTP as described 
in Section 6.III-8. 

(b) The PFTP shall be provided with a communications interface to be 
determined by the Contract Administrator at Preliminary Design Review 
(CDRL 2). 



(c) The Contractor shall develop a demonstration plan that identifies 
strategies for minimizing or eliminating paperwork for collecting daily 
ridership data, reporting and managing vanpool revenue. 

(d) The Vanpool Demonstration shall test as a minimum: 

i. The use of all pass and stored value fare payment methods 
accepted on fixed route services for vanpool fare payment. Multi¬ 
ride will not be considered a valid payment for vanpools. 

ii. Fare payment for both regular and infrequent riders. 

iii. Transfers between vans. 

iv. Transfers between vans and fixed route transit services. 

v. The allocation of subsidies for vanpool services and use, 
including subsidized passes and the Electronic Voucher 
Program. 

vi. Methods for easily downloading transaction data and uploading 
new tables and parameters to the PFTP. 

(e) The Contractor shall provide vanpool utilization reports that shall 
include as a minimum van identification (numbers provided by the 
Agencies), driver identification, fare and transaction details, transfers 
between vans, and transfers between vans and other transit services. 

(f) The Demonstration shall identify or present the conceptual design for the 
proposed work process and information flow for vanpool providers to 
receive and transmit information to the Clearinghouse System. 

Use of RFCS Card on Vanpools Not Equipped with PFTPs 

(a) Back office data reporting and integration shall be used to allow 
customers with an RFCS card to use vanpools that have not been 
equipped with PFTPs. 

(b) A customer shall have the option of linking their fare card to a specific 
vanpool using the vanpool ID at Agency customer service offices, or by 
telephone, mail or Internet. 

(c) The Internet Website shall include capabilities to generate monthly, 
weekly or ad-hoc reports of all RFCS cards linked to the vanpool, 
summarizing by card the fare products loaded and status (value, period 
pass validity, etc.). 



(d) Reports shall be available to the vanpool driver or Agency vanpool 
administrator. Different access privileges (to be defined at Preliminary 
Design Review) shall be established for the driver and vanpool 
administrator. 

(e) Reports shall also include vanpool subsidy information. 

11.1.6.2 Paratransit 

A Paratransit application shall be provided for King County Metro that supports 
two modes of operation. 

1. Equipping paratransit Vehicles with PFTPs to read RFCS fare cards. A 
decision to proceed with paratransit application and final schedule will be 
determined at PDR (CDRF 2). 

2. Providing back-office integration to allow customers with an RFCS card to 
use Paratransit vehicles that are not equipped with PFTPs. This functionality 
shall be implemented as part of Phase I. 

Fare options for Paratransit customers shall include the KCM Access pass. 

Paratransit Vehicles Equipped with PFTPs 

(a) Paratransit vehicles shall be equipped with full function PFTPs as 
described in Section 6.III-8. 

(b) The PFTPs shall be equipped with IEEE 802.11b communications as 
described in 6.III-8.5(b).iii, and a vehicle charger as described in 6.III- 
8.4.3. 

(c) Paratransit bases shall be equipped with WDOFS base equipment as 
described in Section 6.III-7, and DACs equipment as described in 
Section 6.III-12. 

Back-Office Integration 

(a) A customer with an RFCS card loaded with an Access pass shall be able 
to use both vehicles equipped with PFTPs, and vehicles without. 

(b) Back office integration shall be used to provide Access dispatch services 
with information on customer eligibility as follows: 

i. The fare card shall include an Access pass category and client ID 
number provide by KCM. 

ii. Fare cards configured as Access passes shall only be issued at or 
through a King County customer service office. Clients will 



provide eligibility information to the King County customer 
service representative when procuring the pass. 

iii. Fare cards configured as Access passes shall be eligible to use the 
Autoload payment functionality, with custom design features to 
recognize that the Access pass on an ORC A fare card is typically 
not tapped at a fare payment device. 

(c) The RFCS, through the Back Office Client computer, shall provide, on a 
daily basis, a list of active Access passes and client ID numbers in ASCII 
flat file format. This file will be imported into King County’s Trapeze 
system for linking to the daily manifest. 

(d) The clients Access pass status will be printed on the daily drivers 
manifest to provide verification of eligibility without requiring the client 
to present a card to an FTR 

6.11-11.2 Engineering and Design 

The Contractor’s program for RFC system engineering shall consist of the following 
activities: 

(a) Industrial and Human Factors Design 

(b) System Design and Design Reviews 

11.2.1 Industrial and Human Factors Design 

Industrial design principles shall be employed throughout the equipment design 
and manufacturing processes. 

(a) Industrial design aspects of the FTP configurations, Driver Display Unit 
and Revaluing Devices, shall be reviewed during the scheduled design 
review meetings. 

(b) Design calculations, layouts, and other documentation summarizing the 
human factors engineering considerations shall be submitted during the 
design reviews( to be included in a section of the DR documents for each 
device). 

(c) Topical reviews to address key issues shall be held as needed. 

(d) Documentation shall include the following: 

i. Description of the assumptions concerning human capabilities 
and limitations. 

ii. Results of any simulation programs employed to determine the 
human factors design requirements. 



11.2.2 System Design and Design Reviews 


(a) Design reviews shall be conducted incrementally in Groups as specified 
in revised Figure II-11.3 and revised Figure II-11.6 to evaluate the 
progress and technical, functional and programmatic adequacy of the 
RFCS design in accordance with the performance requirements of the 
Contract during design and engineering. 

(b) Prior to each review, a design review package shall be submitted that 
includes all Design Review (DR) items listed in Figure II-11.3. 

(c) Design review packages shall be provided at least 30 days before a 
design review meeting. The Contractor shall conduct a formal design 
review for each Group within PDR and FDR as defined in revised Figure 
II-11.3 and revised Figure II-11.6 as well as new Figure II-11.2.2.2 and 
new Figure II-11.2.2.3. Each review will be conducted per the 
guidelines specified in Sections 6.II-11.2.2.2 and 6.II-11.2.3. 

11.2.2.1 Conceptual Design Review (CDR) 

The objectives of the CDR (CDRL 1) is to familiarize the Agencies with the 
Contractor’s intended design and procurement activities, resolve external 
interfaces, and provide the basis for proceeding to PDR. 

(a) The CDR shall cover the following: 

i. Schedule compliance review and discussion of variances or 
delays. 

ii. Confirm the Contractor’s management team and the scope for 
each subcontractor. 

iii. Provide a functional block diagram of the system and equipment. 

iv. Provide a top level data model illustrating the major functional 
entities and relationships. 

v. Provide outlines of all Design Review (DR) items indicated in 
Figure II-11.3. 

vi. Provide narrative descriptions of the major subsystems proposed 
by the Contractor, including identification of components 
supplied by subcontractors for each equipment type. 

vii. Identify all interfaces between the major subsystems, provide a 
schedule, and identify responsibilities for completion of detailed 
definition of the interfaces. 

viii. Confirm that the Contractor is familiar with the intended 
operations and maintenance environment. 

ix. Provide outline and format of customer interface messages. 



x. Provide physical dimensions of each equipment type. 

xi. Identify power and other facility requirements for each 
equipment type. 

xii. Identify information needs and decisions required from the 
Agencies. 

xiii. Provide description of problem tracking, resolution and reporting 
process. 

xiv. Description of all required Clearinghouse services. 

(b) Nine (9) copies of the submittals shall be provided prior to CDR in paper 
and electronic format. Each drawing submittal shall include one 
reproducible on Mylar, sepia, or equivalent. 

11.2.2.2 Preliminary Design Review (PDR) 

The objective of the PDR (CDRL 2) is to review the progress of the project and 
evaluate specification compliance of the completed work and/or work in 
progress. 

(a) The PDR shall represent approximately 50% completion of the total 
engineering and organizational design. The PDR shall cover the 
following: 

i. Schedule compliance review and discussion of variances or 
delays. 

ii. Provide draft documentation for all DR items indicated in Figure 
II-11.3. 

iii. Revisions of drawings and documentation submitted for the 
CDR. 

iv. Complete customer and user interface information and drawings, 
flow charts, server graphics, messages and menus, including 
accommodations of all operating boundary and error conditions. 
Customer and user interface information shall include as a 
minimum: user interface description, field level definitions, 
function key (or other control) definitions and processing logic, 
implemented business rules and/or special processing logic, 
CRUD (create, read, update, delete) functions, and access and/or 
security restrictions. 

v. Detailed technical descriptions of all RFCS equipment. 

vi. Detailed interface descriptions, including mounting arrangements 
and installation methods. 

vii. Sample cards (disposable and revalue) including all logos and 
designs. 



viii. Single-line power diagrams and functional block diagrams for 
each device, including a functional overview and a description of 
how each device or subcomponent goes out of service. 

ix. Systems architecture physical and logical diagrams that map the 
RFCS to the National ITS Architecture Standards. 

x. Detailed data model describing entities, attributes, data dictionary 
and meta data. 

xi. Communications interfaces. 

xii. List of all data file formats. 

xiii. List of special tools and software requirements. 

xiv. Description of operational and physical compatibility with the 
existing equipment and equipment installations. 

xv. Detailed human factors engineering results. 

xvi. Design of access control for the equipment and the software 
menus. 

xvii. Software system-level flow-charts. 

xviii. Software data backup and recovery procedures. 

xix. Software design descriptions (top level of software 
documentation) for microprocessor-based or programmable 
equipment. 

xx. Clearinghouse processes. 

xxi. Software version and configuration control system. 

xxii. On-board equipment mock-ups. 

xxiii. Design of all required Clearinghouse services. 

xxiv. Draft reports and formats including as a minimum: report 

description, reporting data set, all user parameters indicating 
required or optional, each field definition including data source 
and any calculations, special formatting requirements, access or 
security restrictions. 

(b) All PDR reviews shall be conducted at a location approved by the 
Contract Administrator. 

(c) Nine (9) copies of the specific submittals shall be provided prior to PDR 
in paper and electronic format. Each drawing submittal shall include one 
reproducible on Mylar, sepia, or equivalent. 

(d) With each PDR submittal, the Contractor will provide a schedule for 
workshops to review each document with the Agencies. These 
workshops will begin not earlier than 15 days following the design 



review meeting and will be working sessions in which document changes 
and clarifications may be made. The intent of these workshops is to 
reduce to a minimum the comments that need to be submitted formally at 
the end of the 40 day review period and facilitate mutual understanding 
of the design and any design concerns. It may not be possible to 
incorporate all necessary changes and clarifications during the workshop 
but the Parties will attempt, at a minimum, to identify the areas of 
concern to be electronically noted for Contractor or Agency follow-up. 

Figure 11-11.2.2.2 Preliminary Design Review Content 


Item ID 

Description 

Group 

i. 

Schedule compliance review and discussion of variances or delays 

All 

ii. 

Provide draft documentation for all DR items indicated in Figure II- 
11.3 

See revised 

Figure II-11.3 

iii. 

Revisions of drawings and documentation submitted for the CDR 

See revised 

Figure II-11.3 

iv. 

Complete customer and user interface information and drawings, 
flow charts, server graphics, messages and menus, including 
accommodations of all operating boundary and error conditions. 
Customer and user interface information shall include as a minimum: 

• user interface description 

• field level definitions 

• function key (or other control) definitions and processing logic 

• implemented business rules and/or special processing logic 

• CRUD (create, read, update, delete) functions 

• access and/or security restrictions 

Group 1 and Group 

2 - CST 

V. 

Detailed technical descriptions of all RFCS equipment 

Hardware Group 
and Group 2 -CST 
is in Group 2 

vi. 

Detailed interface descriptions, including mounting arrangements and 
installation methods 

Hardware Group 
and Group 2 

vii. 

Sample cards (disposable and revalue) including all logos and designs 

Group 2 

viii. 

Single-line power diagrams and functional block diagrams for each 
device, including a functional overview and a description of how 
each device or subcomponent goes out of service 

Hardware Group 

ix. 

System architecture physical and logical diagrams that map the RFCS 
to the National ITS Architecture Standards. 

Group 2 

X. 

Detailed data model describing entities, attributes, data dictionary and 
meta data 

Group 2 

xi. 

Communications interfaces 

Group 2 

xii. 

List of all data file formats 

Group 2 

Xiii. 

List of special tools and software requirements 

Group 1 

xiv. 

Description of operational and physical compatibility with the 
existing equipment and equipment installation 

Group 1 

XV. 

Detailed human factors engineering results 

Group 1 

xvi. 

Design of access control for the equipment and the software menus 

Group 1 

Xvii. 

Software system-level flow-charts 

All 

Xviii. 

Software data backup and recovery procedures 

Group 3 

xix. 

Software design descriptions (top level of software documentation) 
for microprocessors- based or programmable equipment 

Group 1 

XX. 

Clearinghouse processes 

Group 2 

xxi. 

Software version and configuration control system 

Group 3 





























Item ID 

Description 

Group 

Xxii. 

On-Board Equipment mock ups 

Hardware Group 

Xxiii. 

Design of all required Clearinghouse services 

Group 2 

Xxiv 

Draft reports and formats including as a minimum: report description, 
reporting data set, all user parameters indication required or optional, 
each field definition including data source and any calculations, 
special formatting requirements, access or security restrictions 

Group 2 


11.2.2.3 Final Design Review (FDR) 

The objective of the FDR (CDRL 3) is to determine whether the detailed design 

satisfies the design requirements established in the Contract documents. 

(a) The FDR shall be conducted when detailed design is complete. 

(b) All DR documents listed in Figure II-11.3 shall be prepared in final 

form. 

(c) The FDR shall cover the following: 

i. Schedule compliance review and discussion of variances or 
delays. 

ii. Provide all FDR Items indicated in Figure II-11.3. 

iii. Latest revisions of the drawings and documentation submitted for 
the PDR. 

iv. Shut-down and start-up sequences. 

v. Demonstrate compatibility with existing Agency equipment. 

vi. Assembly drawings down to the lowest replacement unit level. 

vii. Electrical schematic drawings, down to the individual signal or 
wire level, for each electrical circuit. 

viii. Flow charts or structure charts that give an overview of the 
processor software. 

ix. Software documentation at the second level, consisting of the 

data model (entities, attributes, data dictionary and meta data) to 
the lowest level of decomposition with software module 
descriptions (or elemental process descriptions) in structured 
narrative format. The second level of software documentation is 
one level above source code and should include descriptions for 
each equipment type. 

x. Input data definitions. 

xi. Output data definitions. 

xii. Interrupt structure definition. 










xiii. Program parameters. 

xiv. Diagnostic routines for processor self-test and subsystem self¬ 
test. 

xv. Error handling routines. 

xvi. Data dictionary. 

(d) The Contract Administrator shah have on-site access to drawings and 
other design and manufacturing information related to manufacturing 
release of devices, including microprocessor source code and other 
proprietary technical data, but only to the extent the Contractor in the 
ordinary course of its business keeps such source code or other 
proprietary technical data on its site. 

(e) On-site access shah be provided at the Contractor’s facility. The 
Contractor may establish suitable confidentiality agreements. 

(f) For the purpose of requirements (d) and (e) above, access shah not 
include the right to make copies, either electronic or physical, of 
materials made available to the Contract Administrator. 

(g) Nine (9) copies of the specific submittals shah be provided prior to FDR 
in paper and electronic format. Each drawing submittal shah include one 
reproducible on Mylar, sepia, or equivalent. 

Figure II - 11.2.2.3 Final Design Review Content 


Item ID 

Description 

Group 

i. 

Schedule compliance review and discussion of variances or delays 

All 

ii. 

Provide all FDR items indicated in Figure II-11.3 

See revised 

Figure II-11.3 

iii. 

Latest revisions of the drawings and documentation submitted for the 
PDR 

See revised 

Figure II-11.3 

iv. 

Shut-down and start-up sequences 

Group 2 

V. 

Demonstrate compatibility with existing Agency equipment 

Hardware Group 

vi. 

Assembly drawings down to the lowest replacement unit level 

Hardware Group 

vii. 

Electrical schematic drawings, down to the individual signal or wire 
level, for each electrical circuit 

Hardware Group 

viii. 

Flow charts or structure charts that give an overview of the processor 
software 

Group 2 

ix. 

Software documentation at the second level consisting of the data 
model (entities, attributes, data dictionary and meta data) to the 
lowest level of decomposition with software module descriptions (or 
elemental process descriptions) in structures narrative format. The 
second level of software documentation is one level above the source 
code and should include descriptions for each equipment type 

Group 2 

X. 

Input data definitions 

Group 2 

xi. 

Output data definitions 

Group 2 

xii. 

Interrupt structure definition 

Group 2 

xiii. 

Program parameters 

Group 2 

xiv. 

Diagnostic routines for processor self-test and subsystem self-test 

Group 1 





















Item ID 

Description 

Group 

XV. 

Error handling routines 

Group 1 

xvi. 

Data dictionary 

Group 2 


11.2.3 Design Baseline 


(a) 

For the purposes of change control, the design baseline for all hardware 
elements will be established upon the completion of review of the 
hardware designs and issuance by the Agencies of a FDR-level Notice 
of Apparent Completion for the Hardware Group, which shall be 
processed separately from the PDR and FDR processes for Group 1, 2 
and 3. The design baseline for all other program elements shall be 
established at the FDR.. 

(b) 

The Contractor shall submit to the Contract Administrator for approval 
changes beyond FDR that affect the design characteristics agreed to at 
FDR. 

11.2.4 Mock-Ups and Prototype Equipment 

11.2.4.1 Mock-Ups 

The Contractor shall provide mock-ups of equipment designs for evaluation 
during any of the three design reviews. 

(a) 

Mock-ups shall be either real equipment, or if real equipment is not 
available, a substitute media subject to the review and approval of the 
Contract Administrator. 

(b) 

Presentation of all customer and Agency personnel interface panels, 
operation and display messages shall be subject to mock-up for use in 
focus groups. 


11.2.4.2 Prototype Equipment 

The Contractor shall provide prototypes of each custom designed equipment and 
operational software that allows evaluation under simulated operation in an in- 
service environment. The prototype shall include at least the following: 

(a) Fully operational unit 

(b) All interfaces operational 

(c) All software and firmware operational 

(d) Customer interface functions. 









Any prototype equipment that requires few or no changes may be used as the 
unit designated for Factory Acceptance Testing (FAT) subject the review and 
approval of the Contract Administrator. 

11.2.5 Production Baseline 

(a) The equipment and software production baseline shall be established 
after the completion of the Beta Test. 

(b) Changes beyond the completion of the Acceptance Testing associated 
with the Beta Test shall be documented in the form of change requests 
and submitted for approval. 

Figure II-11.3 

Division II Design Review Items 


DR 

Reference 

Description 

Group 

1 

6.II-1 

Customer Service Functions 

Group 2 

1.01 

6.II-1.2.2 

Agency Customer Service Equipment and Services 

Group 2 

1.02 

6.II-1.2.5 

Internet Website 

Group 2 

1.03 

6.II-1.2.5 

Website Accessibility 

Group 2 

1.04 

6.II-1.3.1 

Call Center Standards and Metrics 

Group 2 

1.05 

6.II-1.3.1 

On-Line Knowledge Database 

Group 2 

1.06 

6.II-1.3.2 

Website Standards and Metrics 

Group 2 


2 

6.II-2.2.1 

Common Institutional Program Requirements 

Group 2 

2.01 

6.II-2.2.2.1 

Right-to-Ride Program 

Group 2 

2.02 

6.II-2.2.2.2 

Electronic Voucher Program 

Group 2 

2.03 

6.II-2.2.2.3 

Customized Product Program 

Group 2 

2.04 

6.II-2.2.2.4 

Campus Program 

Group 2 

2.05 

6.II-2.2.2.5 

Human Service Programs 

Group 2 


3 

6.II-3.1 

Card Procurement and Distribution 

Group 2 

3.01 

6.II-3.2.2 

Card Order and Shipping Documentation 

Group 2 


4 

6.II-4.1 

Fare Card Management 

Group 2 

4.01 

6.II-4.2.2 

Card Initialization Information 

Group 2 

4.02 

6.II-4.2.3 

Card Account Data Archive Access 

Group 2 


5 

6.II-5.1 

Clearinghouse Services 

Group 2 

5.01 

6.II-5.2.1.2 

Daily Processing Functions 

Group 2 

5.02 

6.II-5.2.2 

Reconciliation and Settlement 

Group 2 

5.03 

6.II-5.2.2 

Claims Fund 

Group 2 

5.04 

6.II-5.2.3 

Data Upload and Download 

Group 2 

5.05 

6.II-5.2.4 

System Interface and End Point Management 

Group 2 

5.06 

6.II-5.2.5 

Fare Table Management 

Group 2 

5.07 

6.II-5.2.6 

Fraud Management 

Group 2 

5.08 

6.II-5.2.8 

Database Management 

Group 2 























































DR 

Reference 

Description 

Group 

5.09 

6.II-5.2.9 

Audit 

Group 2 


6 

6.II-7.1 

Financial Management 

Group 2 

6.01 

6.II-7.2.1 

Cash Management 

Group 2 

6.02 

6.II-7.2.2 

Fee Management 

Group 2 

6.03 

6.II-7.2.3 

Merchant of Record 

Group 2 


7 

6.II-8.1 

Communications Network 

Group 1 

7.01 

6.II-8.2.3 

Network Management 

Group 1 

7.02 

6.II-8.2.4 

Data Management 

Group 1 


8a 

6.II-9 

Revalue Network Equipment and Services 

Hardware Group 

8.01 

6.II-9.1 

Revalue Network Systems and Support 

Hardware Group 


8b 

6.II-9 

Revalue Network Equipment and Services 

Group 1 

8.01 

6.II-9.1 

Revalue Network Systems and Support 

Group 1 


Division III Design Review Items 


DR 

Reference 

Description 

Group 

101 

6.III-2 

Fare Card 

Group 1 

101.01 

6.III-2.2.1 

Card Operating System 

Group 1 

101.02 

6.III-2.2.1 

Contactless Interface 

Group 1 

101.03 

6.III-2.2.2 

Disposable Card 

Group 1 

101.04 

6.III-2.2.4 

Smart Objects 

Group 1 

101.05 

6.III-2.4.3 

Card Data 

Group 1 

101.06 

6.III-2.4.4 

Card Graphics Standards 

Group 1 

101.07 

6.III-2.7.2 

Campus Cards 

Group 1 


102a 

6.III-3 

Fare Transaction Processor 

Hardware Group 

102.01 

6.III-3.2.2 

Smart Card Interface 

Hardware Group 

102.02 

6.III-3.2.3 

Customer Interface and Display 

Hardware Group 

102.03 

6.III-3.4 

Physical Appearance and Styling 

Hardware Group 

102.04 

6.III-3.6.1 

Communications Interface 

Hardware Group 

102.05 

6.III-4.1 

On-Board Fare Transaction Processor 

Hardware Group 

102.06 

6.III-4.1 

OBFTP Architecture 

Hardware Group 

102.07 

6.III-4.4 

Prototype OBFTP Configurations 

Hardware Group 


102b 

6.III-3 

Fare Transaction Processor 

Group 1 

102.01 

6.III-3.2.2 

Smart Card Interface 

Group 1 

102.02 

6.III-3.2.3 

Customer Interface and Display 

Group 1 

102.03 

6.III-3.4 

Physical Appearance and Styling 

Group 1 

102.04 

6.III-3.6.1 

Communications Interface 

Group 1 

102.05 

6.III-4.1 

On-Board Fare Transaction Processor 

Group 1 

102.06 

6.III-4.1 

OBFTP Architecture 

Group 1 

102.07 

6.111-4.4 

Prototype OBFTP Configurations 

Group 1 


103a 

6.III-6 

Driver Display Unit 

Hardware Group 

103.01 

6.III-6.2.1 

Keyboard 

Hardware Group 





















































































DR 

Reference 

Description 

Group 

103.02 

6.III-6.2.2 

Display 

Hardware Group 

103.03 

6.III-6.2.2 

DDU Message Sets 

Hardware Group 

103.04 

6.III-6.8.1 

DDU Interface Control Document 

Hardware Group 

103.05 

6.III-6.8.2 

Electronic Farebox Integration 

Hardware Group 

103.06 

6.III-6.8.3 

King County RCU Integration 

Hardware Group 

103.07 

6.III-6.8.4 

Community Transit Integration 

Hardware Group 

103.08 

6.III-6.8.5 

Application Certification 

Hardware Group 


103b 

6.III-6 

Driver Display Unit 

Group 1 

103.01 

6.III-6.2.1 

Keyboard 

Group 1 

103.02 

6.III-6.2.2 

Display 

Group 1 

103.03 

6.III-6.2.2 

DDU Message Sets 

Group 1 

103.04 

6.III-6.8.1 

DDU Interface Control Document 

Group 1 

103.05 

6.III-6.8.2 

Electronic Farebox Integration 

Group 1 

103.06 

6.III-6.8.3 

King County RCU Integration 

Group 1 

103.07 

6.III-6.8.4 

Community Transit Integration 

Group 1 

103.08 

6.III-6.8.5 

Application Certification 

Group 1 


104a 

6.III-7 

Wireless Data On/Off Loading System 

Hardware Group 

104.01 

6.III-7.1 

On-Board WDOLS Equipment 

Hardware Group 

104.02 

6.III-7.1 

WDOLS Equipment at Transit Bases 

Hardware Group 

104.03 

6.III-7.6 

WDOLS Data Exchange 

Hardware Group 

104.04 

6.III-7.7 

Wireless Security Protection 

Hardware Group 

104.05 

6.III-8.5 

PFTP WDOLS Equipment 

Hardware Group 


104b 

6.III-7 

Wireless Data On/Off Loading System 

Group 1 

104.01 

6.III-7.1 

On-Board WDOLS Equipment 

Group 1 

104.02 

6.III-7.1 

WDOLS Equipment at Transit Bases 

Group 1 

104.03 

6.III-7.6 

WDOLS Data Exchange 

Group 1 

104.04 

6.III-7.7 

Wireless Security Protection 

Group 1 

104.05 

6.III-8.5 

PFTP WDOLS Equipment 

Group 1 


105a 

6.III-8.1 

Portable Fare Transaction Processor 

Hardware Group 

105.01 

6.III-8.1 

Verifier Only 

Hardware Group 

105.02 

6.III-8.1 

Full Function PFTP 

Hardware Group 


105b 

6.III-8.1 

Portable Fare Transaction Processor 

Group 1 

105.01 

6.III-8.1 

Verifier Only 

Group 1 

105.02 

6.III-8.1 

Full Function PFTP 

Group 1 


106a 

6.III-9.1 

Stand Alone FTP 

Hardware Group 

106.01 

6.III-9.1 

Sound Transit SAFTP Configuration 

Hardware Group 

106.02 

6.III-9.1 

WSF SAFTP Configuration 

Hardware Group 


106b 

6.III-9.1 

Stand Alone FTP 

Group 1 

106.01 

6.III-9.1 

Sound Transit SAFTP Configuration 

Group 1 

106.02 

6.III-9.1 

WSF SAFTP Configuration 

Group 1 


107 

6.III-10.1 

Integration with Sound Transit TVMs 

Group 2 

























































































DR 

Reference 

Description 

Group 

107.01 

6.III-10.1 

TVM Credit/Debit/Cash Interface 

Group 2 

107.02 

6.111- 10.1 

6.111- 10.7 

TVM/CDCS Communications Interface 

Group 2 

107.03 

6.111- 10.1 

6.111- 10.4 

Customer Display and Interface 

Group 2 

107.04 

6.111- 10.5 

6.111- 10.8 

Installation and UL Requirements 

Group 2 


108 

6.III-11.1 

Customer Service Terminal 

Group 2 

108.01 

6.III-11.4 

CST CPU 

Group 2 

108.02 

6.III-11.4 

Magnetic Card Reader-encoder 

Group 2 

108.03 

6.III-11.4 

PIN pad 

Group 2 

108.04 

6.III-11.4 

Agent Display 

Group 2 

108.05 

6.III-11.4 

Customer Display 

Group 2 

108.06 

6.III-11.4 

Card Reader/Writer 

Group 2 

108.07 

6.III-11.4 

Keypad/board 

Group 2 

108.08 

6.III-11.4 

Printer-Receipt 

Group 2 

108.09 

6.III-11.4 

Cash drawer 

Group 2 

108.10 

6.III-11.4 

Equipment to Create Photo IDs 

Group 2 

108.11 

6.III-11.4 

Card Dispensing Module 

Group 2 

108.12 

6.III-11.4 

Data communications 

Group 2 

108.13 

6.III-11.4 

Secure Access Module (SAM) 

Group 2 

108.14 

6.III-11.10 

KCM POS Integration 

Group 2 


109 

6.III-12.1 

Data Collection System (DACS) 

Group 2 

109.01 

6.III-12.3 

Data Processing Plan 

Group 2 


110 

6.III-13.1 

Back Office Client Application 

Group 2 

110.01 

6.III-13.2.1.2 

Fare Table Administration 

Group 2 

110.15 

6.III-13.4.1 

Back Office Client Computer 

Group 2 

110.16 

6.III-16.7 

WSF Integration 

Group 2 


111 

6.III.13.1 

Back Office Reporting 

Group 3 

111.01 

6.III-13.2.2.1 

King County Metro Reporting 

Group 3 

111.02 

6.III-13.2.2.2 

Kitsap Transit Reporting 

Group 3 

111.03 

6.III-13.2.2.3 

Pierce Transit Reporting 

Group 3 

111.04 

6.III-13.2.2.4 

Community Transit Reporting 

Group 3 

111.05 

6.III-13.2.2.5 

Everett Transit Reporting 

Group 3 

111.06 

6.III-13.2.2.6 

Sound Transit Reporting 

Group 3 

111.07 

6.III-13.3.1 

Standard System Performance Reporting 

Group 3 

111.08 

6.III-13.3.1 

System Maintenance Reports 

Group 3 

111.09 

6.III-13.3.2.1 

National Transit Database Reporting 

Group 3 

111.10 

6.III-13.3.2.2 

Common Ridership and Revenue Reporting 

Group 3 

111.11 

6.III-13.3.3 

Ad-hoc Fare Card Ridership and Revenue Reporting 

Group 3 

111.12 

6.III-13.3.4 

Agency Specific Fare Card Ridership and Revenue Reporting 

Group 3 

111.13 

6.III-13.3.5 

Non-Fare Card Transaction Reporting 

Group 3 



































































6.11-11.3 Installation 


11.3.1 Installation at Agencies 

The Agencies will be responsible for vehicle and site preparation per 
requirements provided by the Contractor in design reviews, and will be 
responsible for the installation of equipment in vehicles, rail platforms and ferry 
terminals. The Contractor shall provide supervisory, technical support for 
equipment installed by Agencies. 

The Agencies will be responsible for site preparation for equipment installed at 
Agency facilities. Unless otherwise directed by an Agency, the Contractor shall 
be responsible for the installation, testing and commissioning of equipment 
installed in Agency facilities including data acquisition computers, customer 
service terminals, base-mounted wireless data on-off load devices, back office 
computers, and related equipment. 

(a) The Contractor shall be responsible for the delivery of RFCS equipment 
and materials to designated Agency locations. Shipping shall be FOB 
destination with freight, taxes and duties prepaid. The Contractor shall 
also be responsible for providing local storage and transportation prior to 
delivery. 

(b) The Contractor shall coordinate with a respective Agency representative 
and installation shall comply with individual Agency requirements. 

(c) The Contractor shall provide all required vehicle and facility mounting 
and installation hardware. 

(a) The Contractor shall specify the requirements for the physical 
installation of equipment and systems at each site including at a 
minimum space requirements, environmental requirements, 
communications requirements and connections, and electrical 
requirements. 

(b) The Agencies will be responsible for the installation of conduit for 
power lines and data communication lines in Agency facilities and for 
the installation of such lines on Agency premises. 

(c) The Contractor shall provide any power conditioning and un¬ 
interruptible power supply equipment. 

(d) The Contractor’s responsibility for installation of equipment at facilities 
shall include the bolt down of equipment, the connection to power and 
data communication lines, and the installation testing of equipment to 
ensure that the units installed are fully functional. 



(e) The installation of on-board equipment shall occur at the relevant 
Agencies facilities (garage, base) per the requirements of Section 6.III- 
4.7. The Agencies will be responsible for installation. 

(f) The Contractor shall be responsible for all supervision, technical support, 
system testing, commissioning and performance. Subject to individual 
Agency approval, the Contractor may conduct final commissioning, 
inspection, testing and certification of on-board equipment on “groups” 
of vehicles after installation by the Agency. 

11.3.2 Installation Procedures 

(a) The Contractor shall supply detailed procedures for equipment 
installation and inspection: 

i. This shall include installation checklists, identifying the 
equipment, software, installation configurations and settings and 
other characteristics applicable to the installation process and 
parameters, and unique to the equipment being installed and the 
Agency/property of the installation. 

ii. The Procedures shall provide sufficient information to verify 
proper installation and interfacing of the equipment with other 
system facilities. 

(c) Installation checklists shall be submitted to the Contract Administrator a 
minimum of forty-five (45) days prior to scheduled installation, and shall 
be subject to the approval of the Contract Administrator and the affected 
Agency. 

(d) The Contractor shall inform the Contract Administrator, in writing, of 
any unacceptable conditions during installation. The Contract 
Administrator will determine what corrective action needs to be taken. 
Any additional work required of the Contractor will be negotiated and 
handled through the change order process. 

(e) The Contractor shall notify the affected Agency a minimum of seventy- 
two (72) hours, excluding weekends and holidays, prior to the scheduling 
of any inspection at a particular site, and will not conduct any inspection 
without Agency representation. 

6.11-11.4 Testing Requirements 

11.4.1 Overview of Testing 

All of the components, subsystems and systems processes constituting the RFCS 

shall be tested individually and together to ensure that they meet the Contract 

requirements and provide a properly functioning system. The work under this 



section shall include all labor, materials, and support services required to 
completely inspect and test all hardware and software. 

In addition to the qualification, integration and other internal testing it performs. 
Contractor shall be responsible for the performance of all of the tests described 
below to satisfy the objectives of each testing phase as determined by the 
Contract Administrator. The Agencies and/or its associates shall oversee the 
performance of the tests described below. 

The following outlines the testing sequence and describes the different testing 
stages: 

(a) Factory Acceptance Tests (FAT) 

Factory Acceptance Testing shall be performed to ensure that the 
supplied and developed components meet all functional and 
environmental requirements and specifications. Factory Acceptance 
Tests shall be performed on each type of equipment prior to it being 
delivered to any Agency. 

For further details concerning the Factory Acceptance Tests refer to 
Section 11.4.2. 

(b) System Integration Tests (SIT) 

System Integration Testing shall be performed to verify that subsystem 
components, when integrated together, meet the system level functional 
requirements and specifications. System Integration Testing is 
completed prior to onsite installation of the system except as otherwise 
provided in Section 11.4.3. 

Permission for the Contractor to commence SIT in accordance with 6.II- 
11.4.3.3 shall not relieve the Contractor of continuing to perform Phase 1 
Factory Acceptance Testing (H-FAT and F-FAT) until all requirements 
for same have been completed and the Agencies have issued a Notice of 
Apparent Completion (NAC). 

For further details concerning the System Integration Tests refer to 
Section 11.4.3. 

(c) Installation Test 

Following onsite installation of the equipment, Installation Testing shall 
be performed. Installation Tests are used to determine if the equipment 
delivered to the installation site has been installed correctly and 
functions, component wise, to the requirements and specification. 



For further details concerning the Installation Tests refer to 
Section 11.4.4. 

(d) System Commissioning 

During the System Commissioning testing phase the installed and 
integrated system is verified to function according to the system wide 
requirements. System Commissioning is completed prior to placing the 
system into revenue service, both prior to the Beta Test and prior to the 
Full System Acceptance Test. 

For further details concerning the System Commissioning Test refer to 
Section 11.4.5. 

(e) Beta Test 

The Beta Test phase begins when a subset of each Agency’s equipment 
is placed into revenue service. The Beta Test includes a subset of the 
systems and services to be provided for the full RFCS implementation. 
The objective of the Beta Test is to confirm the functional acceptability 
of the RFC systems and services under revenue service operation before 
implementing the full RFCS. 

For further details concerning the Beta Tests refer to Section 11.4.6. 

(f) Acceptance Testing 

Following successful completion and Agency approval of the Beta Test, 
full implementation of the RFCS will proceed. Acceptance testing will 
be performed on all equipment and services placed into revenue service 
to demonstrate the performance of the system as a whole. The 
completion of the Acceptance Testing will be contingent upon the 
system meeting specified performance levels. 

For further details concerning Acceptance Testing refer to Section 
11.4.7. 

The relationship of the specified test requirements up to completion of the Beta 
Test is shown in the flowchart provided in Figure II-11.4. 

The relationship of the specified test requirements up to completion of the Full 
RFCS Rollout is shown in the flowchart provided in Figure II-11.5. 



Figure 11-11.4 

Relationship Of Phase I Testing 
(Beta Test) 



















Figure 11-11.5 

Relationship Of Phase II Testing 
(Full RFCS Rollout) 
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1.4.2 Factory Acceptance Tests (FAT) 


The Contractor shall provide a comprehensive Factory Acceptance Test (FAT) 
program (CDRL 14) that shall consist of the following individual test programs: 


l. 


Functional Test 
















ii. Environmental Test 

iii. Electromagnetic Interference Test 

iv. Radiated Electromagnetic 

v. Human Factors Test 

(a) Each equipment type and all of its functions shall be subject to the FAT 
unless waived by the Contract Administrator. 

(b) One item of each equipment type shall be tested as specified in this 
section 11.4.2 and the accepted Factory Acceptance Test Plan (CDRL 
14). 

(c) If the Contractor can prove by certification of using authority, property, 
or independent testing organization that equipment manifestly similar to 
that specified here has been subjected to testing to the extent specified, 
the associated test may be waived, subject to the Contract 
Administrator’s approval. The Contractor shall submit independently 
verified tests to the Contract Administrator for approval at least sixty 
(60) days prior to the scheduled start date for the FAT. Whether a test is 
completed or waived by the Contract Administrator, the Contractor 
agrees, as also provided in Section 3.1-7, that it retains full responsibility 
to deliver System equipment and functions that comply with the Contract 
requirements. 

(d) Factory Acceptance Testing shall be performed in controlled, laboratory 
conditions at a Contract Administrator approved factory or independent 
facilities. 

11.4.2.1 Functional Test 

The purpose of this test shall be to demonstrate that for each RFCS equipment 

type, the functions specified throughout the Contract documents, including all 

limiting conditions, shall be met. 

(a) The equipment shall be required to execute all hardware and software 
functions as detailed in these specifications and to meet the performance 
criteria requirements. 

(b) The Contractor shall be responsible for developing a functional test 
procedure that satisfactorily demonstrates all equipment functions and 
shall submit this test procedure to the Contract Administrator for 
approval thirty (30) days in advance of the test. 

(c) Each function specified shall be tested at least once prior to confirming 
success or failure. Each equipment type shall have passed a full 
hardware diagnostic test before the environmental tests are started. 



11.4.2.2 Environmental Test 


Environmental tests shall be performed one (1) time per on-board and outdoor 
equipment and shall be tested per SAE Recommended Practice J1455 JAN88, as 
follows: 

(a) Test 1 The Thermal Shock Test shall be per Section 4.1.3.2 of the 
aforementioned SAE Recommended Practice, and shall use the thermal 
profile portrayed in Figure 2C of said section, except that: 

i. The storage temperature limits shall be 25 to +150 degrees 
Fahrenheit. 

ii. The presoak shall be 2 hours at 25 degrees Fahrenheit. 

iii. Hour 24 to hour 25 shall be at 70 degrees Fahrenheit. 

Functional tests shall occur immediately prior to and after the 25 hour 
test period. 

(b) Test 2 The Thermal Cycle Test shall be per Section 4.1.3.1 of the 
aforementioned SAE Recommended Practice, and shall use the thermal 
profile portrayed in Figure 2B of said section, except that: 

i. The temperature limits shall be 10 to +135 degrees Fahrenheit. 

ii. The chamber temperature shall be held for two (2) hours 
minimum at the 10 degrees Fahrenheit, followed by two (2) hours 
minimum at +135 degrees Fahrenheit, followed by two (2) hours 
minimum at +70 degrees Fahrenheit. 

iii. Tests shall occur immediately prior to and every thirty 

(30) minutes during the test period, which will terminate at eight 
(8) hours minimum, provided that all conditions above are 
satisfied. 

(c) Test 3 The Humidity Test shall be per Section 4.2.3 of the 
aforementioned SAE Recommended Practice, and shall use the humidity 
profile portrayed in Figure 3A, Recommended Humidity 8 Hour Cycle, 
of said section, except that: 

i. Temperature limits shall be 10 to +135 degrees Fahrenheit. 

ii. Humidity shall be 95% relative humidity (non-condensing). 

(d) Test 4 The Waterfront Test shall be conducted per an approved Waterfront 
Testing Plan to be prepared by the Contractor. No guidelines/standards 
currently exist for the testing of equipment to be used in an outdoor 
marine environment, such as that of the WSF. The Contractor shall 
prepare a comprehensive test plan, designed to demonstrate the 
operability of the equipment in the WSF environment, to 



be conducted at the WSF docks. This Test Plan shall be subject to the 
approval of the Contract Administrator and WSF. 

11.4.2.3 Electromagnetic Testing 

(a) Equipment shall be tested for electromagnetic compatibility per Section 

6.III-1.7.1. 

(b) Equipment shall not sustain any permanent damage as a result of the 
exposure to electromagnetic fields nor shall it lose any data. 

(c) Testing shall take into account the conditions existing at Agency 
facilities including the radar emissions and radio transmissions from 
WSF ferry operations, as well as bus tunnel and trolley conditions. 

11.4.2.4 Radiated Electromagnetic Energy Test 

The Contractor shall identify requirements and demonstrate compliance with 
applicable Federal Communication Commission (FCC) regulations concerning 
conducted and radiated radio frequency energy. 

11.4.2.5 Human Factors Test 

The human factors test shall verify that features and operating characteristics 
affecting the use of the RFCS by customers and Agency personnel are easy to 
understand, easy to use, and quick in response to customer and Agency 
personnel actions. The test shall be designed to evaluate items such as the 
following: 

(a) Time to perform a transaction. 

(b) Time to reset the device. 

(c) Time initialize the device from a complete power down. 

(d) Time to switch between various operating modes. 

(e) ADA compliance with regard to customer operation controls and 
instructions. The Contractor will provide a written statement prior to 
completion of Factory Acceptance Testing describing how the devices 
have been designed to comply with the ADA regulations and guidelines. 



11.4.2.6 Weekly Report 


The Contractor shall continue to conduct Phase 1 FAT and shall provide a report 
each Wednesday, until a NAC is issued, that includes the following: 

(a) the results of all FAT tests and re-tests conducted to-date, as required 
under Section 6.II-11.4.8.5 of the Contract and documented in CDRL 14 
Factory Acceptance Test Plan; 

(b) for any Phase 1 FAT test that fails or is designated by the Contractor as 
“conditionally passed” or “not applicable (n/a)”, the weekly report shall 
describe in detail the reason the test was not passed, details of the 
problem or defect encountered, how the Contractor proposes to address 
the problem or defect, when the problem or defect will be resolved, what 
if any documents are required to be updated, for all test identified as 
“conditionally passed” or “not applicable (n/a)” after the execution of 
this Agreement; and 

(c) for each RFCS function that has not yet been subjected to Factory 
Acceptance Testing, the weekly report shall describe how and by when 
that function will be subjected to Factory Acceptance Testing. 

11.4.2.7 Resolution of Failed FAT Tests 

If a FAT test is failed, and the problem or defect is assessed to be a severity 1 or 
2 per the classifications in Table 8 of CDRL 23, then the Contractor shall make 
such modifications to the hardware or software as are needed until the test is 
passes as part of the Phase 1 FAT. If a FAT test is failed but the problem or 
defect is assessed, with Contract Administrator agreement, to be a severity 3 or 
4, then the Contractor shall make such modifications to the hardware or software 
as are needed until the test is passed in a re-test no later than the completion of 
Post-Beta FAT for modified Systems. 

11.4.2.8 Completion of Phase 1 FAT Milestone 

The following must be satisfactorily performed by the Contractor in order to 
complete the Phase 1 FAT Milestone and obtain the issuance of the required 
NAC; 

(a) Satisfactory completion of all Contract requirements, including Section 
6.II-11.4.2 and CDRL 14; 

(b) All RFCS functions have been tested including any scripts currently 
classified by the Contractor as “no-run”, except those tests as mutually agreed 
through request documentation changes; 



(c) All Phase 1 FAT tests have passed except for those in which the problem 
or defect has been assessed, with Agency agreement, as a severity 3 or 4; 

(d) All required reports as required by Section 6.II-11.4.8.5 of the Contract 
and documentation in CDRL 24 have been completed; and 

(e) Any Agency-agreed changes to the Contract requirements and design 
documents for FAT-related items have been confirmed in signed-writings. 

11.4.3 Systems Integration Test 

The goal of Systems Integration testing is to connect each RFCS Subsystem and 
demonstrate the functionality as a fully integrated system prior to on site 
installation. 

11.4.3.1 System Integration Test Plan 

Contractor shall develop a System Integration Test Plan (CDRL 16) identifying 
how each subsystem is integrated such as communications, protocols, and data 
relationships, including any boundary conditions and security provisions. The 
Test Plan shall describe procedures to be followed for demonstrating the 
following, at a minimum: 

(a) Alarm transmission and all other device/component monitoring 
functions. 

(b) Data transmission, including all control functions, between devices and 
the DACS. 

(c) Data transmission between devices, DACS and Clearinghouse System. 

(d) Data integrity and security. 

(e) Credit and debit card transaction approvals and rejections (all types). 

(f) Check transaction approvals and rejections. 

(g) Funds reconciliation and settlement. 

(h) Report generation and transmission to Agencies. 

(i) Bad card rejections and lockout. 

(j) Auto revalue of cards. 

(k) Operating ranges for each type of equipment. 

(l) Performance measures. 



(m) Data encryption/security provisions for each type of data transfer. 


(n) All data transmissions shall be inspected for accuracy. Inaccurate data 
transmissions shall be recorded as a failure of the particular test for 
which the transmission was performed. 

(o) End-to-end scenario testing and business rule testing as specified in the 
accepted System Integration Test Plan (CDRL 16). 

(p) The procedures for handling maintenance (troubleshooting and 
correcting faults) and service functions shall also be written and 
demonstrated. 

(q) ADA compliance with regard to customer operation controls and 
instructions. 

(r) Facilitation of transit operator-customer interaction as human factor. 

(s) The System Integration Test Plan also describe procedures for the 
Contractor to conduct a maintainability test that consists of introducing 
faults into the equipment and systems, and then measuring the time 
required for a technician to correct the fault. 

i) The Maintainability Test Plan (CDRL 15) shall show the basis of 
sample size selection and list of faults, including a reasonable 
time limit for repair performed by an average technician based on 
field experience, to be introduced into the equipment. This list 
shall represent every known failure mode for each unit of 
equipment and system, next to each fault, the Contractor shall 
identify. 

ii) The maintainability test shall be conducted in the following steps: 

a. The Contractor shall provide several units of the 
equipment to the Contract Administrator to simulate 
failed components, mis-adjustments, and incorrect 
settings. 

b. The simulated failures shall be introduced in proportion to 
their expected failure rate. 

c. The Contractor’s maintenance personnel shall be unaware 
of the simulated failures and shall be assigned to 
troubleshoot the equipment. 



d. The repair times shall be recorded and the mean-time-to- 
repair (MTTR) shall be compared with the advance list 
provided by the Contractor. 

iii. Maintainability Test results shall be reviewed and approved by 
the Contract Administrator. 

The System Integration Test Plan, including the Maintainability Test Plan shall 
be submitted for the approval of the Contract Administrator a minimum of 
ninety (90) days prior to the commencement of System Integration Testing. 

11.4.3.2 RFCS Test Bed 

a. The Contractor shall provide a test-bed located in the Puget Sound Area. 
Equipment representing each Agency’s equipment and configuration shall be 
assembled in a single test-bed (“RFCS test-bed”) to permit interconnection to 
simulate the overall RFCS configuration and operation. The RFCS test-bed shall 
be used to perform, among other things, device testing, device interface and 
integration testing, including systems integration and configuration data testing 
and administration. 

It is not required that the Central System or DACS which support financial and 
operational data processing be co-located at this site, but it must be possible to 
interconnect to them using the telecommunications processes to be used in the 
installed system environment. The RFCS central system (clearinghouse, servers 
and associated systems and networks) shall be connected to the test bed to 
support full operation of all systems and subsystems in the RFCS test bed. The 
RFCS testbed also includes the devices, connections and network that enable 
Washington State Ferries (WSF) to remotely access an RFCS Release in the 
testbed in order to test it in conjunction with other WSF hardware and software 
that are integrated with the RFCS. 

b. The test-bed shall be established prior to the commencement of System 
Integration Testing. Each Agency’s actual equipment shall also be utilized in the 
RFCS test-bed to perform end-to-end testing prior to delivery of said Agency 
equipment to Agency facilities. 

c. The Contractor shall be responsible for the test-bed environment until 
completion of Contract. 



The test-bed shall remain operational through the duration of the Contract and 
shall be updated to reflect any changes to the devices, software and/or system 
configuration. 

11.4.3.3 Phase 1 System Integration Testing (SIT) 

11.4.3.3.1 Commencement of Phase 1 SIT 

The Contractor may commence Phase 1 System Integration Testing (SIT) prior to the 
issuance of a NAC for the successful completion of Phase 1 FAT, subject to the terms of 
the plan embodied in Contract Change Agreement #2. Other than allowing for the 
phase commencement of SIT, the Agencies do not intend to modify the testing process, 
procedures, criteria, reports and other requirements of the Contract. 

11.4.3.3.2 Product Business Rules Testing on Front Office Components 

The Contractor shall complete the Product Business Rules Testing by the end of SIT 
Par 1. This shall include any necessary re-testing of Product Business Rules and 
testing of any Product Business Rules requiring end-to-end scenarios. Any defects, 
error or omissions identified during Product Business Rules testing shall be rectified, 
and the devices re-tested, prior to proceeding with the SIT Part 2 testing, unless 
otherwise agreed by the Contract Administrator. 

11.4.3.3.3 SIT Part 1: End-to-End Testing of RFCS 

11.4.3.3.3.1 Unless otherwise agreed by the Contract Administrator, the 
Contractor may not commence SIT Part 1 until: 

a. in advance of the commencement of SIT Part 1, the 
Contractor has provided the reports as required in 6.II- 
11.4.8.5 with regard to the Factory Acceptance Testing (H- 
FAT and F-FAT) of all devices and functions (including 
reports), other than the CCW, IPW and TRU and related 
reports; 

b. the Agencies have issued NAC for CDRF 22C (Detailed 
SIT Procedures) which procedures shall include but are not 
limited to: 

1. Detail procedures for the end-to-end testing of all 
system components as defined in Section 1.0(b); 

2. Identification of those test procedures that will be 
undertaken for the CCW, IPW and TRU under 
SIT Parts 2 and 3; 



3. 


Regression testing procedures to demonstrate that 
the introduction of new system functionality 
related to the CCW, IPW and TRU under SIT 
Parts 2 and 3 does not adversely impact RFCS 
elements and functionality previously tested; and 

d. the Contractor has entered into a subcontract with Moss 
Adams to perform intrusion and other security-related 
auditing in a manner acceptable to the Agencies. Such 
auditing shall be completed prior to the completion of SIT 
Part 1 End-to-End Testing, but is not technically included 
within the body of the SIT Part 1 Testing scripts. 

11.4.3.3.3.2 The Contractor shall continue to conduct SIT Part 1 tests and re¬ 
tests and shall provide a report each Wednesday, until a NAC is issued for Phase 
1 SIT that includes the following: 

a. a written report of the results of all SIT tests and re-tests 
conducted to-date, as required under Section 6.II-11.4.8.5 
of the Contract and documented in CDRL 24; 

b. for any SIT test that fails of is designated by the 
Contractor as “conditionally passes”, the weekly reports 
shall also describe in detail the reason the test was not 
passed, details of the problem or defect encountered, how 
the Contractor proposed to address the problem or defect, 
when the problem or defect will be resolved, what if any 
documents are required to be updated and by when, and 

c. for each RFCS function that has not yet been subjected to 
SIT, the weekly report shall describe how and by when 
that function will be subjected to SIT. 

11.4.3.3.4 SIT Part 2: CCW and TRU 

11.4.3.3.4.1 Unless otherwise agreed by the Contract Administrator, the 
Contractor may not commence SIT Part 2 until: all required FAT 
tests and re-tests of the CCW and TRU have passed or, if they 
failed, the problem or defect has been assessed, with Contract 
Administrator agreement, to be a severity 3 or 4; all required 
reports have been completed; and any Agency-agreed changes to 
the Contract and design document have been confirmed in 
signed-writings. 

11.4.3.3.4.2 The Contractor shall continue to conduct SIT Part 2 tests and re¬ 
tests and shall provide a report each Wednesday, until a NAC is 
issued for Phase 1 SIT, that includes the following: 



a. a written report of the results of all SIT tests and re-tests 
conducted to-date, as required under Section 6.II-11.4.8.5 
of the Contract and documented in CDRL 24; 

b. for any SIT test that fails of is designated by the 
Contractor as “conditionally passes”, the weekly report 
shall also describe in detail the reason the test was not 
passed, details of the problem or defect encountered, how 
the Contractor proposes to address the problem or defect, 
when the problem or defect will be resolved, what if any 
documents are required to be update and by when; and 

c. for each RFCS function that has not yet been subjected to 
SIT, the weekly report shall describe how and by when 
that function will be subjected to SIT. 

11.4.3.3.5 Sit Part 3: IPW 

11.4.3.3.5.1 Unless otherwise agreed by the Contract Administrator, the 
Contractor may not commence SIT Part 3 until: all required FAT 
tests and re-tests of the IPW have passed or, if they failed, the 
problem or defect has been assessed, with Contract Administrator 
agreement, to be a severity 3 or 4; all required reports have been 
completed; and any Agency-agreed changes to the Contract and 
design documents have been confirmed in signed-writings. 

11.4.3.3.5.2 The Contractor shall continue to conduct SIT Part 3 tests and re¬ 
tests and shall provide a report each Wednesday until a NAC is 
issued for Phase I SIT that includes the following: 

a. a written report of the results of all SIT tests and re-tests 
conducted to-date, as required under Section 6.II-11.4.7.5 of 
the Contract and documented in CDRL 24; 

b. for any SIT test that fails or is designated by the Contractor as 
“conditionally passed” by the Contractor, the weekly report 
shall also describe in detail the reason the test was not passed, 
details of the problem or defect encountered, how the 
Contractor proposes to address the problem or defect, when 
the problem or defect will be resolved, what if any documents 
are required to be updated and by when; and 

c. for each RFCS function that has not yet been subjected to 
SIT, the weekly report shall describe how and by when that 
function will be subjected to SIT. 


11.4.3.3.6 


Resolution of Failed SIT Tests 



If any SIT Part 1, 2 and 3 test is failed, and the problem of defect is assessed to 
be a severity 1 or 2, then the Contractor shall make such modifications to the 
hardware or software as are needed until the test is passed as part of the Phase 1 
SIT. If a SIT test is failed but the problem or defect is assessed, with Contract 
Administrator agreement, to be a severity 3 or 4, then the Contractor shall make 
such modification so the hardware or software as are needed until the test is 
passed in a re-test no later then the completions of Post-Beta SIT or Modified 
Systems. 

11.4.3.3.7 Completion of Phase I SIT Milestone 

The following must be satisfactorily performed by the Contractor in order to 
complete the Phase 1 SIT Milestone and obtain the issuance of the required 
NAC. 


a. The Contractor requirements, including Section 6.II-11.4.3 
and CDRL 22, have been satisfactorily completed; 

b. All RFCS function have been tested; 

c. All Phase 1 SIT tests have passed except for those in which 
the problem or defect has been assessed, with Contract 
Administrator agreement, as a severity 3 or 4; 

d. All required reports as required by Section 6.II-11.4.8.5 of the 
Contract and documented in CDRL 24 have been completed; 
and 

e. Any Agency-agreed changes to the Contract and design 
documents have been confirmed in signed-writings. 


11.4.4 Installation Test 

Installation Test shall occur any time a new unit of equipment is added on the 
site or an existing installed unit is exchanged. 

Upon verification of proper installation of the equipment. Contractor shall 
perform a complete post-installation operational test. 

(a) All functions of installed equipment at each location shall be tested 
under the supervision of Agency representative(s) to ensure operation of 
the equipment as specified. 

(b) An Installation Test Plan shall be submitted to the Contract 
Administrator a minimum of sixty (60) days prior to scheduled 



Installation Testing, and shall be subject to the approval of the Contract 
Administrator. 

(c) The Contractor shall inform the Contract Administrator, in writing, of 
any failures during Installation Testing. 

(d) The Contractor shall notify the affected Agency a minimum of seventy- 
two (72) hours, excluding weekends and holidays, prior to the scheduling 
of any Installation Tests at a particular site, and will not conduct any 
testing without RFCS and relevant Agency representation. 

(e) On thirty-five (35) days prior notice from the Contract Administrator, the 
Contractor shall provide, on site at Community Transit, a qualified 
software engineer to test and complete the integration of the DDU 
application described in 6.III-6.8.4. 

11.4.5 System Commissioning 

Upon completion of Installation Testing, prior to the Beta Test and prior to Full- 
System Acceptance Testing, all system interfaces and integration functions shall 
be tested to verify proper operation of the installed RFCS as a whole: 

(a) The Contractor shall develop a System Commissioning Plan (CDRL 17) 
to demonstrate that all systems are fully operational prior to entering 
revenue service. 

(b) The System Commissioning Plan shall identify and describe all 
necessary tests to verify proper interfacing and installation of the 
equipment with other system facilities, including at a minimum: 

i. Schedule for system commissioning. 

ii. Commissioning test period. 

iii. Procedures for collecting and verifying data from each type of 
equipment. 

iv. Procedures for verifying the correct transfer of control commands 
to each type of equipment. 

v. Test reports content to be prepared. 

(c) The System Commissioning Plan shall be submitted to the Contract 
Administrator a minimum of ninety (90) days prior to scheduled System 
Commissioning Test, and shall be subject to the approval of the Contract 
Administrator. 

(d) The Contractor shall inform the Contract Administrator, in writing, of 
any failures during System Commissioning Testing. 



(e) The Contractor shall notify the affected Agency a minimum of seventy- 
two (72) hours, excluding weekends and holidays, prior to the scheduling 
of any System Commissioning Tests at a particular site, and will not 
conduct any testing without RFCS and relevant Agency representation. 

(f) System Commissioning Testing, as described herein and as specified by 
RFCS, shall be performed at the Agencies facilities. 

11.4.6 Beta Test 

The RFCS Beta Test shall demonstrate the same level of system functionality 
and the services to be provided for full RFCS rollout, and involving Agency 
personnel just as the full system would require, only on a smaller scale. The 
Beta Test shall involve the exercise of the small scale system under revenue 
service conditions. All functional requirements of the RFC system shall be 
tested. The estimated equipment quantities for each Agency for the Beta Test 
are listed in Appendix A. 

11.4.6.1 Beta Test Objectives 

The primary objectives of the Beta Test shall be to: 

(a) Validate that the system meets the functional, operational, and technical 
specifications of the fare card program as defined in the RFP under 
revenue operations. 

(b) Ensure that the fare card technology, system design and implementation 
meet the internal needs of the individual Agencies in the Region for AFC 
systems and services, including any specific requirements or constraints 
with respect to physical implementation or operational processes. 

(c) Provide an assessment of, and field experience with, equipment 
reliability and maintenance requirements. 

(d) Provide an overall assessment of the program cost effectiveness and 
fiscal impact for each Agency. 

(e) Determine the appropriate scope of full rollout based upon the outcomes 
of Beta Test evaluation. 



11.4.6.2 Beta Test Settling In Period 


The initial period following commencement of revenue service in the Beta Test 
stage will be known as the Beta Test Settling In period. This period will provide 
a short time for the Contractor and the Agencies to correct minor 
implementation errors in advance of Beta Testing. The Beta Test Settling In 
period will consist of a minimum of ten (10) days. 

11.4.6.3 Changes to Agency Business Processes 

(a) The Contractor shall provide information to each Agency regarding each 
aspect of Beta test implementation, operation, and evaluation that 
impacts existing Agency operations. This information will be used by 
each Agency to update their business practices. At a minimum, impacts 
and required changes shall be identified in the areas of: 

i. Customer service 

ii. Revenue management and reporting 

iii. Ridership data management 

iv. Training 

v. Equipment installation 

vi. Equipment operation 

vii. Equipment testing and maintenance 

viii. Computer and network operations 

ix. Inventory and fare media management 

x. Public transportation operations 

(b) Changes required to existing Agency business practices shall be 
identified a minimum sixty (60) days prior to the scheduled start of the 
Beta test. 

11.4.6.4 Test Equipment, Documentation and Training 

All test equipment, documentation and training required for the Beta test shall 
be provided by the Contractor a minimum sixty (60) days prior to the scheduled 
start of the Beta test. 

11.4.6.5 Beta Test Plan 

(a) The Contractor shall prepare and submit a Beta Test Plan (CDRL 18) to 
the Contract Administrator for review and approval ninety (90) days 
prior to the scheduled start of the Beta test. 

(b) At a minimum, the Beta Test Plan shall include: 



i. Schedule of all development, installation testing and 
implementation activities. 

ii. Description of proposed tests, procedures, recording methods, 
and test equipment per Section 6.II-11.4.8. Included in this shall 
be a series of control tests where specific transactions can be 
traced end-to-end through the system. 

iii. Contractor recommendations of fare cards and infrastructure 
elements required to meet the objectives of the Beta test. 

iv. Agency training and documentation. 

(c) The Agencies reserves the right to make changes to the Beta Test Plan as 
required and deemed necessary to meet and evaluate Beta test objectives. 

(d) The final Beta test infrastructure is subject to approval and confirmation 
by the Agencies. 

11.4.6.6 Certification of Beta Test Readiness 

Prior to beginning the Beta Test, the Contractor shall submit a Certification of 
Beta Test Readiness (CDRL 19) to the Contract Administrator. At a minimum, 
the Certification of Beta Test Readiness shall certify that: 

(a) The Contractor has completed and the Contract Administrator has 
accepted the Beta Test Plan and all related procedures; 

(b) The Contractor has submitted and the Contract Administrator has 
accepted all deliverables required to be submitted prior to conducting the 
Beta Test; 

(c) The Contractor has submitted and the Contract Administrator has 
accepted all required intellectual property documentation; 

(d) The Contractor has provided all training required to be conducted prior 
to beginning the Beta Test; 

(e) The Contractor has satisfied all applicable pre-test conditions imposed 
by this Contract or the accepted Beta Test Plan; 

(f) The Contractor has completed all applicable software coding; 

(g) The Contractor has completed installation of all equipment to be used in 
the Beta Test; 

(h) All required systems are integrated, on-line, and ready for use; 



(i) The Contractor will conduct the Beta Test in complete conformity with 
the Beta Test Plan and the Contractor is aware of no matters which will 
adversely affect its ability to do so; 

(j) The Contractor is ready to begin the Beta Test immediately. 

(k) Unless otherwise agreed by the Contract Administrator, the Beta Test 
Readiness Milestone shall not be achieved until the following are met: 

i. all Factory Acceptance Testing and all System Integration Testing 
have been completed and there are no problems or defects assessed, 
with Contract Administrator agreement, to be severity 1 or 2; 

ii. all design documentation, training materials, manuals and other 
documents have been revised to reflect any Agency-agreed changes 
to Contract requirements and design documents; and 

iii. all items in the Certification of Beta Test Readiness have been 
satisfactorily complete 

If .4.6.6.1 Phased Conduct of Beta Test 

Notwithstanding any provision to the contrary in the Contract and the Beta 
Test Plan (CDRL 18), the parties agree that the Beta Test shall be conducted 
in accordance with the following terms. The Contractor shall update the 
Beta Test Plan (CDRL 18) prior to the commencement of the Beta Test. 
Other than as provided herein, the parties do not intend to modify the testing 
process, procedures, criteria, reports and other requirements of the Contract. 

All Provisions of Section 6.II-11.4.6.2 remain in effect. 

11.4.6.7.1 Beta Test Stream One (Use by Agency Employees Only) 

Beta Test Stream One shall commence after the Settling-In Period and shall continue 
until the completion of Streams Two and Three. During Stream One, all RFCS 
functions shall be in operation but used by testers from within the Agencies. 

11.4.6.7.2 Beta Test Stream Two (Use By Non-Institutional Customers) 

Stream Two of the Beta Test shall commence no sooner than completion of all internal 
Agency Front Office and Back Office staff Training. During Beta Test Stream Two, the 
RFCS shall be in use by general public customers (non-institutional program). 

11.4.6.7.3 Beta Test Stream Three (Institutional Programs and Website) 

Stream Three of the Beta Test shall commence no sooner than completion of all IPW- 
associated internal Agency staff training. 



During Stream Three all RFCS functions of the RFCS shall be in operation and used by 
Agency staff (per Stream One), general public customers (per Stream Two), and 
institutional program customers. 

11.4.6.8 Resolution of Beta Problems or Defects 

If a problem or defect is identified in the Beta test and is assessed to be a severity 1 or 2 per the 
classifications in Table 8 of CDRL 23, then the Contractor shall make such modifications to the 
hardware or software as are needed until the test is passed as part of the Beta test. If such 
problem or defect is assessed, with Contract Administrator agreement, to be a severity 3 or 4, 
then the Contractor shall make such modifications to the hardware or software as are needed 
until the test is passed in a re-test no later than the completion of Post-Beta FAT for Modified 
Systems. 

11.4.6.9 Beta Test Acceptance Criteria 

The following must be satisfactorily performed by the Contractor in order to complete the Beta 
Test Acceptance Milestone and obtain the issuance of the required NAC. 

a. a NAC has been issued for Phase 1 FAT and Phase 1 SIT; 

b. the Contract requirements, including Section 6.II-11.4.6 and CDRL 18, have 
been satisfactorily completed; 

c. all RFCS functions have been tested; 

d. all Beta tests have passed except for those in which the problem or defect has 
been assessed, with Contract Administrator agreement, as a severity 3 or 4; 

e. all required reports as required by Section 6.II-11.4.8.5 of the Contract and 
documented in CDRL 24 have been completed; and 

f. any Agency-agreed changes to the Contract and design documents have been 
confirmed in signed-writings. 



The Contractor shall not commence the Beta Test until the Contract 
Administrator has issued a Notice of Apparent Completion for the Beta Test 
Readiness Milestone per Section 3.1-27.6. The Contractor shall promptly 
provide any documentation or information requested by the Contract 
Administrator to assist in the Contract Administrator’s review of the 
Certification or the Contractor’s state of readiness. 

11.4.7 Acceptance Test 

Acceptance testing shall be performed at a system level after (a) the issuance of 
an unconditional Notice of Apparent Completions for the Complete System 
Commissioning Milestone; (b) the requirements of section 6.II-11.4.7.1 for 
ending the Settling-In period have been satisfied; and (c) Go Live has started 
with all components and subsystems completely functional, operational, on-line, 
and in service; and (d) the Contractor has met the requirements for 
commencement of the acceptance testing provided in Section 3.1 of Amendment 
#62.. 

(a) Acceptance testing shall be conducted by the Contractor in cooperation 
with Agency personnel and shall be subject to review and approval by 
the Agencies. 

(b) Reliability calculations for a particular equipment type in a group will 
remain consistent throughout the acceptance testing period. 

(c) The Agencies reserve the right to make changes to the Acceptance 
Testing Plan to demonstrate conformance with the Contract 
requirements. 

11.4.7.1 Acceptance Testing Settling In Period 

The initial period of time commencing on March 2, 2009, and continuing until 
Acceptance Testing commences, as provided in subsection 11.4.7.1(f) below, 
shall be designated as the Acceptance Testing Settling In period. The 
Contractor shall archive data created during development and testing so that the 
Acceptance Testing Settling-In period shall commence with clean databases. 

(a) The Acceptance Testing Settling In period will last for at least thirty (30) 
days prior to beginning Acceptance Testing but not end until the 
requirements for starting Acceptance Testing, as provided in subsections 
11.4.7.1(c) through (f) below, have been met. During the Acceptance 
Testing Settling-In period, all areas of the RFCS System will be 
available for the Agencies’ use, including performing all production 
functionality and conducting training. 

(b) The Parties will cooperated to develop an agreed plan and date for 
commencing the equipment performance monitoring that will determine 



satisfaction of the requirements in subsections (c) through (e) 
below.During the Acceptance Testing Settling In period a failure review 
test process shall be established (CDRL 20) by the Failure Review 
Team. 

(c) At the end of the Acceptance Testing Settling In period the Mean 
Transactions Between Failures (MTBF) for high transaction volume 
equipment of the same type shall be not less than 40% of the MTBFs 
presented in Division III for each type of RFCS equipment. 

(d) For equipment of the same type in a low transaction volume 
environment, the mean operating hours between failures (MOHBF) in a 
group shall be not less than 40% of the mean hours between failures 
presented in Division III for each type of RFCS equipment. 

(e) If at the end of the Acceptance Testing Settling In period the above 
MTBF and mean operating hours between failures (MOHBF) criteria are 
not met, then the reliability of the equipment shall be monitored until 
these criteria are met for thirty (30) consecutive days. 

(f) The Acceptance Testing Settling In period will not end and the 
Acceptance Testing shall not commence until the MTBF and MOHBF 
requirements in (c) and (d) above are met, an unconditional Notice o 
Apparent Completion has been issued for the Milestone of “Completion 
of Complete System Commissioning” and Go Live has started. 

11.4.7.2 Acceptance Test Plan 

Contractor shall develop a Acceptance Testing Plan (CDRL 21). 

(a) The plan shall be a comprehensive and detailed document, describing the 
management, monitoring, recording, and reporting procedures that will 
govern the acceptance testing period. 

(b) The Acceptance Testing Plan shall be submitted to the Contract 
Administrator for review and approval a minimum of ninety (90) days 
prior to the scheduled start of the Acceptance Test period. 

(c) The Agencies reserve the right to make changes to the Acceptance 
Testing Plan to demonstrate conformance with the Contract 
requirements. 

11.4.7.3 Acceptance Test Requirements 

(a) The Full System Acceptance Testing Measurement Period shall begin 
and end as provided in Amendment #52 and shall be conducted over a 
minimum of eight (8) consecutive weeks under revenue service 
conditions 



(b) Should the equipment fail to meet the performance requirements as 
specified herein. Contractor shall make whatever improvements to the 
equipment and/or systems which are needed to meet the requirements. 

(c) Contractor shall continue to improve RFCS equipment and systems until 
the Contract requirements are met. 

11.4.8 General Testing Procedures and Definitions 

11.4.8.1 General Procedures 

For each inspection and test, the Contractor shall: 

(a) Prior to testing or inspection, submit a detailed Test Procedure to the 
Contract Administrator for review and approval (CDRL 22) a minimum 
of thirty (30) days prior to conducting the test. 

(b) Provide check-off sheets for the items to be inspected, measurements to 
be taken, features required to be present, and the criteria required to be 
met. 

(c) Be responsible for all Contractor, Supplier and Subcontractor inspections 
and tests to be performed, including those performed under the 
Contractor’s Quality Assurance plan. 

(d) Any and all hardware and software not passing inspections and/or tests 
and not meeting the approval of the Contract Administrator shall be 
repaired, replaced, and/or corrected by the Contractor and rescheduled 
for inspection and testing. 

(e) Receive approval from the Contract Administrator prior to proceeding 
with any tests or inspections. 

(f) Submit the final report to the Contract Administrator for review within 
thirty (30) days after completion of the inspection or test. 

(g) Retain all inspection and test results for a period of not less than two (2) 
years, during which the results shall be available for Agency review. 

(h) The Agencies reserve the right, at their discretion, to witness any or all 
inspections/tests, using Agency personnel and/or Consultants and 
agents. 

(i) In addition, the Agencies reserve the right to develop additional test 
procedures to be performed by the Contractor or other designated 
organizations. 



(j) The Contractor shall pay all Contractor-incurred travel, accommodation 
and living costs for the witnessing of inspections and tests. 

11.4.8.2 Test Plan 

The Contractor shall prepare a test plan and applicable procedures, that shall 
govern the conduct of activity, surveillance, direction, and methods of observing 
and recording the pertinent data. The Contractor shall provide an Overall 
Inspection and Test Plan (CDRL 23) and specific Test Plans for each specific 
test. The Contract Administrator shall approve the test plan prior to proceeding 
with testing. As a minimum, the following elements shall be included in the test 
plan: 

(a) Dates, times and locations of testing. 

(b) Support and calibration tools and instrumentation to be used. 

(c) Technical publications to be referenced. 

(d) Spares and consumables to be available. 

(e) Maintenance facilities needed. 

(f) Staffing requirements to be met. 

(g) Scheduling of personnel. 

(h) The format and specific data to be collected during the test period 
together with the method used to report the test results. 

(i) Preventive maintenance tasks to be performed during the test. 

11.4.8.3 Test Procedure Outline 

The test procedure shall include, as a minimum, the following: 

(a) Objective of test. 

(b) Test environmental conditions. 

(c) Detailed description of test specimens including drawings, part numbers, 
inspection and test records, maintenance records, and calibration 
records. 

(d) Detailed procedure of test. 

(e) Test equipment to be used, including any measuring equipment and/or 
any equipment aiding in the performance of the tests. 



(f) The level and schedule of preventive maintenance during the test. 

(g) Pass/fail criteria. 

(h) Retest procedure. 

(i) Test data sheet format. 

(j) Test notification to engineer. 

(k) Test reports. 

11.4.8.4 Test Tools and Logging 

At a minimum, the Contractor shall maintain the following capabilities: 

(a) Automated tools for measuring and capturing data packets and data 
flows at each major interface, from end to end, between subsystems. The 
test tools may include standard off the shelf communications software or 
customized in house trace and logging software. In the design review, 
the contractor shall propose a suite of tools and describe the 
methodologies for use. 

(b) Automated test tools shall be thoroughly documented in their use. 

(c) The test plan and procedures shall include the ability to automatically 
identify points of data corruption or transmission failure. 

(d) The reporting of test data must be made in English, and provide the 
ability to sort by time, event type and other key attributes, so that an end 
to end verification of data flows can be readily obtained. 

(e) Event log messages shall be logically grouped and labeled, fully parsed, 
and loaded into a database in a production manner, so that they are 
readily available for troubleshooting and analysis. 

11.4.8.5 Test Reporting 

The Contractor shall provide a complete report documenting the operation and 
reliability during all acceptance testing. The report shall be in a form acceptable 
to the Contract Administrator. Test Reports are contract deliverables under 
CDRL 24. 

To the extent the Contractor’s proposed resolutions submitted under 6.II- 
11.4.2.6 include requests to change Contract requirements or design documents, 
the Contractor shall submit a Change Request to the Agencies, including the 
proposed change, updated language and commented documents within 30 
calendar days of each SIT Part completion. If the Agencies agree to the 



requested change, ERG shall submit the revised document for Agency review. 

If the Agencies do not agree to a change in the Contract requirements or design 
documents, the Contractor shall make such modifications to the hardware or 
software as are needed until the test is passed as part of the Phase 1 FAT. 

To the extent the Contractor’s proposed resolution submitted under Sections 
6.II-11.4.3.3.3.2(b), 6.II-11.4.3.3.4.2(b) and 6.II-11.4.3.3.5.2(b) above include 
requests to change Contract requirements of design documents, the parties shall 
meet to discuss such requests. If the Agencies agree in principle to make a 
requested change, ERG shall submit the actual language change for Agency 
review. Any agreed changes shall be confirmed in a revision to the applicable 
document. If the Agencies do not agree to a change in the Contract 
requirements or design documents, the Contractor shall make such modifications 
to the hardware or software as are needed until the test is passed as part of the 
Phase 1 SIT. 


6.11-11.5 Progress and Performance Monitoring 

The Contractor shall provide a Quality Assurance Program Plan (CDRL 25) specifically for 
this project and such a plan shall be in place and adhered to throughout this project. 
Additionally, the Contractor shall provide an overall Program Management, Progress and 
Performance Monitoring Plan (CDRL 26) which describes how the RFCS program is 
managed, administered, and controlled with respect to contract Administrator Contract 
management processes. 

11.5.1 Progress and Performance Reviews 

For the duration of the Contract, the Contractor shall participate in monthly 

progress and performance reviews in Seattle. 

11.5.1.1 System Design and Engineering, and Implementation 

(a) The Contractor shall participate in regular project status reviews with the 
Agencies and their consultants, and shall provide detailed reports on the 
progress of the RFCS, beginning with the Contract award through the 
completion of the full RFCS rollout. 

(b) These reviews may be held as often as is deemed necessary by The 
Contract Administrator, depending upon the stage and progress of the 
project. 

(c) The reviews may be combined with design review meetings. 



11.5.1.2 Post Rollout 


Once the RFCS rollout is completed, the Contractor shall participate in system 
performance reviews with the Agencies and their consultants, and shall provide 
detailed reports on the performance of the RFCS, including at a minimum the 
following: 

(a) Equipment and system performance: 

i. Failure analysis 

(b) On-time and accurate delivery of Agency reports. 

(c) Number of calls received, at a minimum including, customer service. 
Agency inquiries, maintenance. 

(d) Number of calls responded to, at a minimum including, customer 

service, Agency inquiries, maintenance. 

(e) Average response time for each call category. 

11.5.2 Status Reporting 

The final format of a status report which aggregates the inputs from all parties 
shall be agreed between the Agencies and the Contractor, immediately after 
award of the Contract. The Contractor shall provide Monthly Progress Reports 
(CDRL 27). At a minimum, the following information shall be provided: 

(a) Current Overall Status 

i. Items Delivered 

ii. Items Outstanding 

iii. Progress Versus Implementation Plan 

iv. 90-day look ahead at key workshops, design review and critical 
path items. 

(b) Issues and Resolution 

i. Technical 

ii. Third Parties 

iii. Other 



11.5.3 Problem Reporting 


In addition to status reports issued on an on-going basis, the Contractor shall 
implement a separate problem tracking, resolution and reporting system. 

(a) Problem tracking and resolution report logs shall be provided to The 
Contract Administrator as part of the Fault Tracking and Maintenance 
Performance Report (CDRL 10). 

(b) The degree of automation to be employed for this activity shall be agreed 
between the Contract Administrator and the Contractor, but regardless of 
the degree of automation, it shall perform the following functions at 
minimum: 

i. The system shall assign numbers to problems as they are reported 
to enable accurate tracking. 

ii. Each problem shall be logged on the date reported. 

iii. The log shall be updated as the status of the problem changes and 
provide the following minimum information: 

- Anticipated solution 

- Date solution is to be provided 

- Date solution was provided 

- Date solution was tested 

- Results of the test 

(c) Problems shall not be closed until the solution has been successfully 
tested and has been “signed-off” by the Contractor and the Contract 
Administrator. 

6.11-11.6 Contract Document Requirements List (CDRL) 

11.6.1 Contract Documentation Requirements 

The Contractor shall comply with the requirements for the submission of 
schedules, reports, plans, certificates, and other data listed in the specification 
documents. 

(a) Acceptance of CDRL items are subject to Contract Administrator review 
and approval. 

(b) CDRLs will not be considered complete until formally approved by the 
Contract Administrator. 



11.6.1.1 Document Requirements 


Technical and other required documentation shall be submitted in accordance 
with the Contract Document Requirements List. 

(a) Nine (9) copies of documentation in paper and electronic format shall be 
provided. In addition, each drawing submittal shall include one 
reproducible on Mylar, sepia, or equivalent. 

(b) Figure II-11.6 provides a list of the required CDRLs. 

(c) Unless noted otherwise, CDRLs shall be submitted as follows: 

i. In outline form at Conceptual Design Review. 

ii. In draft form at Preliminary Design Review. 

iii. In final form at Final Design Review. 

Figure II-11.6 

Contract Document Requirements List (CDRL) 


CDRL 

Submittal Description 

Conceptual Design Review 

Reference 

6.II-11.2.2.1 

6.111- 3.2.0 

6.111- 6.2.2 

Notes 

Group 

NA 

1 

2 

Preliminary Design Review 

6.II-11.2.2.2 

6.111- 9.2 

6.111- 1.6.1 

6.111- 1.6.2 


NA 

3 

Final Design Review 

6.11- 2.2.2.5 

6.11- 11.2.2.3 


NA 

4 

Call Center and Internet Standards, Metrics, and 
Reports 

6.11- 1.3.1 

6.11- 1.3.2 


Group 3 

5 

System Backup and Recovery Plan 

6.11- 5.2.8 

6.11- 8.2.3 

6.111- 1.4 

6.111- 3.8 


Group 3 

6 

NSF Plan 

6.II-7.2.1 

(3) 

Group 2 

7 

Revalue Network and Support Services Plan 

6.II-9.3 


Group 1 

8 

Maintenance Plan 

6.II-10.I 

3.1-58.1.3 

(3) 

Group 3 

9 

System Wide Spares Inventory Report 

6.II-10.1 

(1) 


10 

Summary Fault Tracking and Maintenance 
Performance Report 

6.11- 10.1 

6.11- 11.5.3 

3.1-58.1.4 

(1) 


11 

Telephone Support Procedures and Performance 
Measurements 

6.II-10.2.2 


Group 3 

12 

Telephone Support Statistics Report 

6.II-10.2.2 

(1) 


13 

Implementation Plan 

6.11- 11.1.1 

6.11- 11.1.5 

(2) 























CDRL 

Submittal Description 

Factory Acceptance Test (FAT) Program 

Reference 

6.II-11.4.2 

Notes 

(2) 

Group 

14 

15 

Maintainability Test Plan 

6.II-11.4.2.5 

(2) 


16 

System Integration Test Plan 

6.II-11.4.3.1 

(2) 


17 

System Commissioning Plan 

6.II-11.4.5 

(2) 


18 

Beta Test Plan 

6.II-11.4.6.5 

(2) 


19 

Certification of Beta Test Readiness 

6.II-11.4.6.6 

(2) 


20 

Failure Review Process 

6.II-11.4.7.1 

(2) 


21 

Acceptance Testing Plan 

6.II-11.4.7.2 

(2) 


22 

Test Procedures 

6.II-11.4.8.1 

(2) 

Group 3 

23 

Overall Inspection and Test Plan 

6.II-11.4.8.2 

(2) 


24 

Test Reports 

6.II-11.4.8.5 

(2) 


25 

Quality Assurance Program 

6.II-11.5 

(2) 


26 

Program Management and Progress Plan 

6.II-11.5 

(2) 


27 

Monthly Progress Reports 

6.II-11.5.2 

(1) 


28 

Training Program Plan 

6.11-12.1.1 

(2) 

Group 3 

29 

Training Materials 

6.11-12.3 

(2) 


30 

National Architecture Conformance Plan 

6.III-1.2.2 

(3) 

Group 2 

31 

System Security Plan 

6.III-1.3 


Group 2 

32 

Electromagnetic Compatibility Plan 

6.III-1.7.1 


Group 1 

33 

Required Manuals Schedule 

6.III-1.8.2.1 


Group 3 

34 

System Operations Manual 

6.III-1.8.2.4 

(2) 


35 

System Maintenance Manual 

6.III-1.8.2.5 

(2) 


36 

Required Maintenance Tools 

6.III-1.8.2.5 

(2) 


37 

Software Documentation 

6.III-1.8.2.6 

(2) 


38 

Current Parts List 

6.III-1.8.2.7 

(2) 


39 

System Availability Measurement Plan 

6.III-1.5.2 

(3) 

Group 2 

40 

Non-Fare Applications 

6.III-14.1 


Group 2 

41 

Contract Close-Out Transition Plan 

3.1-85 

(2) (3) 

Group 3 

42 

Baseline Project Schedule 


(2) 


43 

Overall RFCS Release Plan 

11.4.7 (a) (b) 

(2) 


44 

Detailed RFCS Release Plan 

11.4.7 (a) (b) 

(2) 



Notes: (1) Include in monthly or other periodic reports. 

(2) CDRL delivery to be coordinated with associated milestone. 

(3) CDRL may be submitted with narrative description of purpose at Conceptual Design 
Review. No outline required. The review of such narrative statements shall be 
performed in accordance with Section 3.1-27.5 of the Contract. The acceptance 
criteria shall be that the narrative satisfactorily demonstrates the contractor’s 
comprehension of the CDRL purpose and the contractor’s role and responsibilities 
to perform the work required. 


6.II-11.7 PHASE 2 DEVELOPMENT AND TESTING PERIOD 








































The following provisions shall apply during the Phase 2 Development and Testing Period which is the 

period that begins with the commencement of Phase 2 and continues through the Milestone 

“Completion of Complete System Commissioning.” The provisions in this Section 11.7 shall control 

in the event of any conflict with other provisions in the Contract. 

6.II-11.7.1 Definitions 

a. Hardware Revisions - any changes to the design or manufacture of ERG-supplied RFCS hardware, 
including but not limited to new hardware or peripherals, new or end-of-life replacement components 
used in existing hardware, and any hardware that has been altered or modified. 

b. Software Revisions - any change to the design or coding of RFCS software or firmware including but 
not limited to new software, software Updates, software Upgrades, or software changes or 
Modifications. 

c. Document Revisions - any changes to the content, format or presentation of a document whether in 
electronic or paper format. 

d. Phase 2 Revisions - Collectively, Hardware, Software and/or Document Revisions that will be provided 
in Phase 2 for use in Full System revenue service, including revisions listed in Section 2 and other 
revisions as may be agreed to by the Parties. 

e. RFCS Release - Collectively, Hardware, Software and/or Document Revisions that are grouped 
together for the purpose of development, testing, and release into the RFCS test and production 
environments. 

f. RTB - the Regional Testbed located in the Contractor’s Seattle facility which includes all equipment, 
software and systems necessary to conduct end-to-end testing of the RFCS, except for banking 
interfaces, ACH file submission and settling with financial institutions. The RTB also includes the 
devices, connections and network that enable Washington State Ferries (WSF) to remotely access an 
RFCS Release in the RTB in order to test it in conjunction with other WSF hardware and software that 
are integrated with the RFCS. 

g. RTB Test Period - The period of time that Agency staff have access to the RTB for the purpose of 
conducting user testing of an RFCS Release. 

h. Overall RFCS Release Plan - a document listing all Phase 2 Revisions, assigning each RFCS Revision 
to an RFCS Release, and providing a schedule of all planned RFCS Releases. 

i. Detailed RFCS Release Plan - a document issued prior to the commencement of work on a specific 
RFCS Release that lists all documents, test plans and test procedures to be utilized and/or revised as part 
of the development, testing and release of the RFCS Release, as well as a proposed schedule of RFCS 
Release and Document Revision activities (including the RTB Test Period agreed to for that RFCS 
Release). 

j. RFCS Release Notes - a document provided with each RFCS Release describing the release content, 
application notes, and release instructions. 



k. Onboard Equipment (OBE) - Units of RFCS equipment installed onboard Agency coaches; the PFTP’s, 
SAFTP’s and GAK’s installed at Sound Transit and at Washington State Ferries; and any of the above 
Test/Training Rigs as defined below. 

l. Test/Training Rigs - Units of Onboard Equipment provided to the Agencies for the purpose of 
testing/training outside of a bus or terminal. 

m. Production System - The RFCS devices and systems to be utilized for operation of the RFCS in Phase 
2, including equipment, networks and systems installed at/to Agency premises, and the RFCS 
clearinghouse and associated services. It is recognized that financial settlement and funds movement 
will occur with use of this system. 

6.II-11.7.2 Scope of Phase 2 (Revisions and System/Services) 

a. The Phase 2 Revision shall consist of (a) the revisions required to resolve all Development 
Issues (DEVIs) that have been identified to date and will be subsequently identified; (b) the 
revisions needed to implement the functionality identified by the Agencies in the numbered 
Requests for Information (RFIs) that are listed in the “Phase 2 Revisions List,” dated September 
26, 2007, attached hereto as CO-26—Appendix A. (Regarding the PFTP, the Parties 
acknowledge open issues exists as to the hardware platform and agree to diligently proceed in 
good faith to decide on the hardware to be used for Phase 2 resolve the cost implications, if any, 
by October 15, 2007. Until the hardware has been selected, the Contractor agrees to defer any 
activities on RFCS RFI 243 that would vary according to the hardware.) The Parties 
acknowledge that RFIs are exchanges of information, not agreements, change orders or 
amendments to the Contract. The purpose of listing the RFIs in CO 26—Appendix A is to 
identify the functionality that will be addressed by the Phase 2 Revisions. As provided below, 
revised design documents will be developed for the Phase 2 Revisions and, upon their being 
issued a NAC, said revised design documents will constitute Contract Documents. The Parties 
acknowledge and agree that the RFIs are not, and shall not be construed to be, Contract 
Documents or parts of the Contract. 

b. The Contractor shall provide and maintain the following systems during the Phase 2 
Development and Testing Period: 

1) The Regional Testbed 

2) The Production System 

Commencing thirty (30) days prior to the First Release being made available for user testing in 
the RTB as provided in Section 76.3.13, and thereafter for the duration of the Phase 2 
Development and Testing Period, the Agencies shall conduct testing of the RFCS through the 
Regional Testbed and/or Production System using Agency staff and designated test personnel. 
The Contractor agrees that its provision of the RTB, the Production System and the services 
described hereunder, and the Agencies access and use of same, shall not (a) trigger any 
maintenance costs or other compensation except for the lump sum provided in Section 3.1- 
76.3.12; or (b) limit, reduce or otherwise affect the Contractor's obligations under the Contract 
including but not limited to its obligations under Section 3.1-52-53 (Pre-Acceptance 
Deficiencies), Sections 3.1-55-63 (Warranties) and Section 6.II-11.4.7 (System Acceptance 
Testing). 

Throughout the duration of the Phase 2 Development and Testing Period, the Contractor shall 
provide the following services and service levels: 
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SERVICE AREA 

SERVICES TO BE PROVIDED 

SERVICE LEVELS 

a. Regional Testbed 
Operation 

The RTB shall provide all RFCS 
functionality except banking interfaces and 
ACT! file submission and settling with 
financial institutions, in a test environment, 
and shall include equipment, services and 
support for each and all of the seven (7) 
RFCS participating Agencies. 

The RTB shall be available for Agency testing 
of RFCS Releases and Agency CD testing from 
9:00 AM to 5:00 PM during normal business 
days and on weekends if necessary to test 
particular fare products. Testing time will be 
scheduled between the Agencies and ERG. 

ERG staff shall be onsite during all RTB 
testing to assist Agency staff. (The Contractor 
agrees that it will provide training courses at 
Agency facilities and not in the RTB.) 

b. Production 

System Operation 

The production system shall include all 
devices, systems and networks required to 
operate the RFCS, whether at Contractor or 
Agency facilities. The Disaster Recovery 
site will be maintained in operation. 

The production system shall be available 24 
hours a day seven days a week, except as 
reasonably required to accommodate planned 
maintenance periods. Such maintenance 
periods shall be coordinated with the Agencies. 

c. Customer 

Service 

The Contractor shall provide Flelp Desk 
services to answer Agency questions and 
inquiries. 

The Seattle Technical Support Flelp Desk shall 
be available from 9:00 AM to 5:00 PM during 
normal business days. 

d. RFCS Websites 

All RFCS websites (Agency Website, 
Business Account Website, Call Center 
Websites) shall be maintained in operation. 

All RFCS websites shall be available per the 
requirements for Production System Operation. 

e. Other Sales 
Channels 

All other sales and revalue channels 
(customer service terminal, terminal retail 
unit, and mail center) shall be maintained in 
operation. 

All other sales channels shall be available per 
the requirements for Production System 
Operation. 

f. Local Servers 
and Networks 

All local servers (data acquisition 
computers, back office computers, and 
related equipment), wired networks, and 
wireless networks shall be maintained in 
operation. 

All local servers and networks shall be 
available per the requirements for Production 
System Operation. 

g. Fare Card 
Procurement and 
Distribution 

At the Agencies request, the Contractor 
shall provide a one-time procurement and 
distribution of up to 1,000 fare cards, at a 
per card price of $4.89 (that includes any 
and all charges for the card and its 
initializing, distribution, management and 
other services), to be used for test purposes 
per the requirements of 6.II-3 of the 

Contract. 

Cards shall be procured and distributed per the 
requirements of 6.II-3 of the Contract. 

h. Fare Card 
Management 

The Contractor shall provide fare card 
management per the requirements of 6.II-4 
of the Contract as required to support 
testing. 

Management services, as required for testing, 
shall be per the applicable requirements of 6.II- 
4 of the Contract. 

i. Financial 
Management and 
Clearinghouse 
Services 

The Contractor shall provide and maintain 
all financial management and clearinghouse 
services per the requirements of 6.II-5 and 
6.II-6 of the Contract. 

The total number of cards in use during 

Clearinghouse services shall be available per 
the requirements for Production System 
Operation. Financial reconciliation settlement 
process shall be initiated, on average, every 
three (3) days, except as required to support 


















SERVICE AREA SERVICES TO BE PROVIDED 


SERVICE LEVELS 



testing shall be less than or equal to 1,000, 
except if required for system stress testing. 

specific test scenarios. Settlement and 
reconciliation timing shall be per Figure 8 of 
Section 6.4 of DR 6 (ERG Document SEA- 
00033). 

j. Maintenance 
Services 

The Contractor shall provide local 
maintenance and repair of RTB and 
Production System devices used in testing. 

The Contractor shall be responsible for repair 
and replacement within two (2) business days 
for any malfunctioning device(s) that are 
covered by On-site Maintenance; and within 14 
calendar days for any malfunctioning device(s) 
that are covered by Depot Maintenance). In the 
event that a repair cannot be completed within 
that period, the Contractor shall supply and 
install a replacement device 

k. General Support 
Services 

In addition to the Seattle Technical Support 
Help Desk, the Contractor shall maintain 
the following support services: 

A. Incident recording and reporting. 

B. Local field support. 

C. Network and device operation 
support. 

The following service levels shall apply: 

A. Incident recording and reporting: The 
Contractor shall hold incident 
reporting teleconferences and 
create/update incident reports in 
accordance with the Incident Review 
Process described in Sec. 11.7.5(b). 

B. Local field support. A local technician 
shall be available to respond to non¬ 
emergency problems or issues at 
Agency facilities from 9:00 AM to 

5:00 PM during normal business days. 
Response shall be within the next 
business day of notification. 

C. Network and device operation support 
shall be supplied via the Help Desk 
from 9:00 AM to 5:00 PM during 
normal business days. 


6.II-11.7.3 Phase 2 Design 

a. For each Phase 2 Revision which contains Hardware Revisions and/or Software Revisions, 
the Contractor shall prepare Document Revisions as required, and shall submit revised design 
documents (DRs and CDRLs) and images of revised website pages for Agency review and 
issuance of a NAC. The RFCS Revision shall not be released for FAT testing until a NAC for 
the revised design documents has been received. 

b. Proposed revisions to documents shall be shown by providing the entire document with 
underlines for new content and strikethroughs for deleted content. Proposed revisions to 
website pages shall be shown by providing images of the proposed revised web pages. 

c. Document Revisions shall be made throughout Phase 2, subject to Agency review and 
issuance of a NAC, to reflect the functionality and processes delivered in Phase 2. Phase 1 
Design documents not needing modification during Phase 2 need not be submitted, however 
with each Document Revision the Contractor shall provide an updated list of all current 












documents listing the document name, identifier, latest revision number, and latest revision 
date. 


6.II-11.7.4 RFCS Release Plans and Testing Plans/Procedures 

a. The Contractor shall submit an Overall RFCS Release Plan (CDRL 43) that lists all Phase 2 
Revisions, and assigns all such Revisions to a scheduled RFCS Release. The Contractor and the 
Agencies shall work together to agree on the assignment of Phase 2 Revisions to a RFCS 
Release, based on the ability of all Parties to support such assignments and the Parties' 
agreement that the highest priority is for the earliest release of those Phase 2 Revisions that 
affect operator training (i.e. any revisions to onboard equipment and functionality) and 
customers (i.e. any revisions to websites). Such Overall RFCS Release Plan shall be subject to 
Agency review and issuance of a NAC before testing commences on any RFCS Release. 

b. With each RFCS Release, the Contractor shall provide the Detailed RFCS Release Plan 
(CDRL 44). Such Plan shall be subject to Agency review and issuance of a NAC before 
development and testing of that RFCS Release. 

c. The Contractor shall provide Factory Acceptance Test (FAT) and Systems Integration Test 
(SIT) plans, procedures and results for each RFCS Release, subject to Agency review and 
issuance of a NAC. 

d. With each RFCS Release, the Overall and Detailed RFCS Release Plans shall be revised and 
resubmitted to the Agencies to reflect any Severity 3 or Severity 4 issues that remain unresolved 
(as provided in Section 11.7.5 below), and any new issues that have been identified. Such 
issues shall be included in a future RFCS Release and so indicated in both the Overall RFCS 
Release Plan and Detailed RFCS Release Plan(s) associated with the future RFCS Release(s). 


6.II-11.7.5 Development of Testing of Each RFCS Release 


a. Development . Once a NAC has been issued for a modified design document related to 
the Phase 2 Revisions in a RFCS Release, the Contractor may commence its development and 
testing activities. 

b. Issue Resolution Process and Issue Severity Classifications. 

The following is a general description of the Issue Resolution Process that will be used as issues 
are reported during the course of the Phase 2 Development and Testing Period, through the 
Milestone of "Completion of Complete System Commissioning." Another process will be 
developed for resolution of issues that arise on systems and equipment being operated in 
revenue service (post Completion of Complete System Commissioning). 

1. All issues reported by either the Contractor or the Agencies shall be entered by the 
Contractor into the Contractor's log, and assigned a tracking reference number (i.e. 
Development Issue or DEVI number in ERG’s issue tracking system) and severity 
classification at the time of identification, according to the following four severity 
classifications. 




Issue Severity Classifications 


Severity 

Definition 

1 - Critical 

(e) 

Critically affects the primary business service, major 
application, or mission critical system; 


(f) 

Materially impacts the Agency’s ability to deliver 
transit service or fare collection; 


(g) 

No workaround is available; 


(h) 

Fatal error, application halt; 


(i) 

Multiple test cases aborted until defect corrected; 


G) 

Critical path schedule impact; 


(k) 

Loss of Production Data; 


(1) 

FHigh priority functionality critically affected; or 


(m) 

Functionality affecting customers, customer service 
representatives, coach operators, fare inspectors, or WSF 
fare collection staff is not available. 


Examples: All CSTs will not launch, Web Site Unavailable, 

2 - Important 

(n) 

The business service, major application, or system is 
seriously affected or implementation stopped; 


(o) 

The system is exposed to potential loss or interruption 
of service; 


(P) 

No acceptable workaround is available; 


(q) 

Serious error, graceful exit; 


(0 

Core functionality or primary interface affected; 


(S) 

Test case(s) cannot continue until defect corrected or 


(t) 

Functionality affecting customers, customer service 
representatives, coach operators, fare inspectors, or WSF 
fare collection staff does not operate as designed. 


Examples: A single CST will not launch, a single Web Service is 
Unavailable, Production Backup Failure 








Severity 

Definition 

3 - Routine 

An 

issue that is not a 1 or 2 Severity and meets one of the 
following criteria: 


(u) 

A business service, major application, or system is 
moderately impacted, no data has been lost, and the 
business service, application, or system is still functioning; 


(v) 

Workaround available; or 


(w) 

Secondary interfaces or functionality affected. 


Examples: Layout of an Agency Website navigation bar 

4 - Low 

An 

issue that is not a 1 or 2 Severity and meets one of the 
following criteria: 


(x) 

Issue or defect requires modifications to testing 
procedures, but does not materially affect test or results; 


(V) 

Workaround available, if required; or 


(z) 

Low visibility error or no functionality impact. 


Examples: Spelling Errors, Minor Documentation Errors (typos), 
Sort Order, colors 


2. If the Agencies identify an issue, they shall inform the Agencies' Contract 
Administrator (C.A.), or designee, who will be responsible for sending, via email, an 
issue report to the Contractor's Project Manager (P.M.), or designee. The issue report 
shall describe the nature of the problem, any investigative or other actions taken prior to 
the report, any results of such actions, and the Agencies' classification of the issue as 
Severity 1, 2, 3 or 4. The Contractor shall acknowledge receipt of any Agency-reported 
issues by assigning it a tracking reference number, and emailing that number back to 
the Agencies' C.A. or designee along with confirmation of, or proposed changes to, the 
initial severity classification. 

3. If the Contractor identifies an issue, it shall assign the issue a tracking reference 
number and email a report to the Agencies' C.A. or designee that includes the tracking 
number, the nature of the problem and an initial severity classification as proposed by 
the Contractor. The Agencies C.A. or designee will confirm receipt of the issue report, 
and confirm or identify proposed changes to, the initial severity classification. 

4. The Contractor shall review all issues, diagnose the cause of the issue and identify 
potential resolution approaches. In the event that the Contractor believes that additional 
investigation is required to confirm a reported issue, the Contractor shall so indicate in 
its acknowledgement of the issue, and shall also identify any recommended follow-up 
actions to be taken by the Contractor and/or Agencies. The issue shall be maintained 
and tracked based on the initial issue report, however its status and severity rating may 
be subsequently revised by mutual agreement based on the results of any additional 
investigation. A reported issue may be closed if neither the Agencies nor the Contractor 
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can reproduce the issue within a reasonable timeframe, in which case the closure shall 
be recorded as "issue not able to be reproduced." 

5. The Contractor shall submit to the Agencies a weekly Test Status Report on the 
status of all testing and issues as recorded in the Contractor’s issues log. 

6. Unless otherwise agreed, the parties shall hold daily meetings during user testing in 
the RTB, and twice weekly during user testing on Agency production equipment, to 
discuss the status of the issues, closure requests, proposed revisions to severity ratings, 
technical questions or clarifications, and the Contractor's diagnosis and proposed 
approach(es) to resolution. For any technical issue discussions, the Contractor and 
Agencies shall provide personnel who are qualified to discuss the issue, investigation 
results and potential approaches to resolution. 

7. The meetings will occur by teleconference, with the Contractor providing the 
teleconference service and the Agencies reimbursing the Contractor the lesser of one- 
half the actual monthly charge for calls made for these meetings or $5,000 per month. 
The Contractor shall provide the Agencies with documentation of the actual charges for 
these calls. Provided, however, the Agencies reserve the right to terminate this 
reimbursement with thirty (30) days written notice save that the Agencies will share the 
charges for calls made for these meetings prior to such notice in accordance with this 
paragraph 7. In such event, the daily meetings shall occur at King Street Center and the 
Contractor and the Agencies shall be responsible for their own costs in providing the 
telephone connection, if any, for their required personnel to participate. 


c. HFAT. The Contractor shall submit Hardware Factory Acceptance Test (HFAT) plans, 
procedures and results for all Hardware Revisions. For all new hardware devices or peripherals, 
new HFAT plans, procedures and results shall be supplied. For any Phase 1 hardware that has 
been modified or has had components changed due to end-of-life or other reasons, the 
Contractor shall resubmit updated versions of the Phase 1 HFAT plans, procedures and results 
providing evidence that the hardware in its revised configuration has passed all applicable tests. 
The Agencies, at their sole discretion and expense, may witness the HFAT tests as scheduled by 
the Contractor. 

All Hardware Revisions included in an RFCS Release must pass HFAT before the RFCS 
Release proceeds to SIT. Hardware Revisions associated with an RFCS Release shall be 
considered to have “passed” HFAT if: 

1) all the Hardware Revisions in the RFCS Release have been tested; and 

2) any hardware-related Severity 1 or 2 issues identified in testing have been fixed, 
tested and passed; and 

3) Seventy-five percent (75%) of the combined hardware-related Severity 3 and 4 
issues identified in testing have been fixed, tested and passed. 

When the Contractor believes that a RFCS Release containing Hardware Revisions has passed 
HFAT, the Contractor shall submit an HFAT Report (CDRL 24A) to the Agencies that lists the 
results of each test of each Hardware Revision. Each HFAT Report shall be subject to Agency 
review and issuance of a NAC. Except for the final RFCS Release, outstanding hardware- 
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related Severity 3 and 4 issues within the 25% maximum shall be added to a subsequent RFCS 
Release related to hardware, and both the Overall and Detailed RFCS Release Plans shall be 
revised in accordance with Section 6.4 above. The final RFCS Release related to hardware 
shall not be considered to have “passed” H-FAT if any Severity 3 or 4 issues related to 

hardware remain unfixed, unless the Agencies, in their sole discretion, agree in writing via their 
Contract Administrator that such issues may be deferred to be fixed during SIT. 

d. FFAT. The Contractor shall submit Functional Factory Acceptance Test (FFAT) plans, 
procedures and results for all Software Revisions. The Agencies, at their sole discretion and 
expense, may witness the FFAT tests as scheduled by the Contractor. 

All Software Revisions included in an RFCS Release must pass FFAT before the RFCS Release 
proceeds to SIT. Software Revisions associated with an RFCS Release shall be considered to 
have “passed” FFAT if: 

1) all the Software Revisions in the RFCS Release have been tested; and 

2) any software-related Severity 1 or 2 issues identified in testing have been fixed, 
retested and passed unless the Agencies, in their sole discretion, agree in writing via 
their Contract Administrator that the issues may be deferred to another RFCS Release; 
and 

3) Seventy-five percent (75%) of the combined software-related Severity 3 and 4 issues 
identified in testing have been fixed, retested and passed. 

When the Contractor believes that a RFCS Release containing Software Revisions has passed 
FFAT, the Contractor shall submit an FFAT Report (CDRL 24B) to the Agencies that lists the 
results of each test of each Software Revision. Each FFAT Report shall be subject to Agency 
review and issuance of a NAC. 

Outstanding software-related Severity 3 and 4 issues within the 25% maximum shall be added 
to a subsequent RFCS Release, and both the Overall and Detailed RFCS Release Plans shall be 
revised in accordance with Section 6.4 above. The final RFCS Release shall be considered to 
have “passed” FFAT if a maximum of 25% of the combined Severity 3 and 4 issues remain 
unfixed, save that any such issues shall be fixed prior to Full System Acceptance. . 

e. SIT, After passing HFAT and/or FFAT (as required for the specific RFCS Release), the 
RFCS Release shall be subjected to System Integration Testing (SIT) in the Contractor’s 
facility, according to the NAC’d test plan and test procedures for that RFCS Release. The test 
procedures shall include: testing of the Revisions in a RFCS Release; “touch point” testing of 
the other elements and functions of the RFCS that are related to, and reasonably likely to be 
affected by, the Revisions in that RFCS Release; and a standard set of tests to be conducted for 
each RFCS Release that demonstrate end-to-end functionality. The Agencies, at their sole 
discretion and expense, may witness the SIT tests as scheduled by the Contractor. 

Each RFCS Release must pass SIT before it may proceed to the RTB. A RFCS Release shall be 
considered to have “passed” SIT if: 

1) all the Revisions in the RFCS Release have been tested; 

2) any Severity 1 or 2 issues related to hardware identified in testing have been fixed, 
tested and passed; 
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3) any Severity 1 or 2 issues related to software identified in testing have been fixed, 
tested and passed unless the Agencies, in their sole discretion, agree in writing via their 
Contract Administrator that the issues may be deferred to another RFCS Release; and 

4) seventy-five (75%) of the combined Severity 3 and 4 issues identified in testing 
have been fixed, retested and passed. 

When the Contractor believes that a RFCS Release has passed SIT, the Contractor shall submit 
a SIT Report (CDRL 24C) to the Agencies that lists the results of: each test of each Revision; 

all “touch point” testing; and the standard tests. Each SIT Report shall be subject to Agency 
review and issuance of a NAC according to the Review Process in Section 3 above. Except for 
the final RFCS Release, outstanding Severity 3 and 4 issues within the 25% maximum shall be 
added to a subsequent RFCS Release and both the Overall and Detailed RFCS Release Plans 

shall be revised in accordance with Section 6.4 above. The final RFCS Release shall be 
considered to have “passed” SIT if a maximum of 25% of the combined Severity 3 and 4 issues 
remain unfixed save that those issues shall be fixed prior to Full System Acceptance. 

f. RTB User Testing. After passing SIT, each RFCS Release shall be installed by the 
Contractor in the Regional Testbed (RTB) at its Seattle facility to enable the Agencies to 
commence user testing. Prior to notifying the Agencies in writing that the RTB is ready for 
them to commence user testing, the Contractor shall conduct that part of installation testing, 
network connectivity testing, testing of updated Configuration Data (CD), functional testing, 
and any other testing necessary to verify the RTB is ready for user testing. 

After receiving said notification, the Agencies shall have a mutually agreeable number of 
business days, which shall not be less than ten (10) business days but not more than twenty (20) 
business days, for scheduled conducting of the user testing in the RTB. The number of business 
days scheduled for user testing shall be specified in the NAC'd Detailed RFCS Release Plan and 
shall include the number of business days reasonably necessary for Agencies to test each RFCS 
Release, given the number and nature of Phase 2 Revisions proposed for inclusion therein. 

The scheduled period specified in the agreed Detailed Release Plan shall be extended as 
required in order to re-conduct or restart failed or suspended tests as defined below under test 
“stop-start criteria”, and/or to reasonably provide the Agencies with sufficient time to test any 
and all revisions associated with the release, as well as conduct end-to-end testing of the system 
through a series of standard tests (regression tests). 

The Contractor shall provide support during the RTB user testing by assigning to the RTB such 
Contractor employees that are knowledgeable about the RTB and the specific RFCS Release 
being tested as necessary. In order for the Contractor to be able to provide such testing support, 
the Agencies shall provide a copy of their RTB User Testing plan to the Contractor at least ten 
(10) business days prior to the scheduled start of RTB testing. 

User testing in the RTB detailed in the RTB testing plan may include, but is not limited to, 
repeating all or some of the SIT test procedures (including “touch point” testing and the 
standard tests) and other tests of the RFCS Release. The Agencies will inform the Contractor of 
issues in accordance with the Incident Review Process specified in Section 6.II-11.7.5(b) above. 

Each RFCS Release must pass User Testing in the RTB before it may proceed to the Production 
System. A RFCS Release shall be considered to have “passed” RTB if: 

1) all the Revisions in the RFCS Release have been tested; 



2) any Severity 1 or 2 issues related to hardware identified in testing have been fixed, 
retested and passed; 

3) any Severity 1 or 2 issues related to software identified in testing have been fixed, 
retested and passed unless the Agencies, in their sole discretion, agree in writing via 
their Contract Administrator that the issues may be deferred to another RFCS Release; 
and 

4) Seventy-five (75%) of the combined Severity 3 and 4 issues identified in testing 
have been fixed, retested and passed. 

Outstanding Severity 3 and 4 issues within the 25% maximum shall be added to a subsequent 
RFCS Release and both the Overall and Detailed RFCS Release Plans shall be revised in 

accordance with Section 6.4 above. The final RFCS Release shall be considered to have 
“passed” RTB User Testing if a maximum of 25% of the combined Severity 3 and 4 issues 
remain unfixed, save that such issues shall be fixed prior to Full System Acceptance.. 

g. Test Stop-Start Criteria. All tests shall be subject to suspension and resumption of the test 
period duration, as follows: 

1) In the event that a Severity 1 or 2 issue is encountered that results in the interruption 
of a test procedure, the test procedure shall be suspended until the issue has been 
rectified. The test procedure shall resume upon rectification of the issue. The testing 
period specified in the agreed Detailed Release Plan shall be extended to allow 
completion of the test procedure as planned. 

2) In the event that the Agencies are unable to execute a test procedure in RTB testing 
due to planned functionality being unavailable or problems with the system, the RTB 
test period specified in the agreed Detailed Release Plan shall be extended until the 
functionality is made available or problems rectified, and the test procedure executed as 
planned. 

3) The above conditions do not apply to those Severity 3 and 4 defects that the parties 
have mutually agreed can be moved to a subsequent RFCS Release. 

h. User Testing on Agency Production Equipment . Upon satisfactory completion of RTB 
testing of each RFCS Release, the RFCS Release will be released into the Agencies’ production 
equipment via the network. The Contractor shall coordinate with the Agencies on the schedule 
of any RFCS Releases into the Agencies' production equipment, and shall provide a complete 
set of RFCS Release Notes with each such RFCS Release. 

In the event that the release of the software into the Agency production equipment creates a 
Severity 1 or 2 issue, the Contractor shall roll-back the RFCS Release to the prior version, and 
shall undertake such corrective action as needed to resolve Severity 1 or 2 issues identified. 

The Agencies may continue testing each RFCS Release on installed production equipment and 
test rigs at Agency facilities except that Contractor shall give the Agencies reasonable notice, in 
accordance with Section 11.7.2(b) above, of any period when the system is unavailable. 
Agencies shall identify issues and the Contractor shall resolve such issues in accordance with 
the Incident Review Process specified in Section 6.II-11.7.5(b) above. Should the resolution of 
an issue require a further Phase 2 Revision, such Phase 2 Revisions shall be described and 
included in a revision to the Overall and Detailed RFCS Release Plans. 



The Agencies acknowledge that such RFCS Release may not represent the final Phase 2 
software, and will make reasonable accommodations to support additional testing and 
maintenance that the Contractor may wish to undertake. 

The final RFCS Release must have been tested in the Agency environment for thirty (30) 
calendar days and all identified issues in all RFCS Releases shall have been closed with Agency 
agreement before the Completion of Complete System Commissioning Milestone may be 
NAC’d. 

i. System Live. To enable the user testing using the RTB and the Agency production 
equipment, the Contractor and the Agencies have agreed that the RFCS shall remain “live” and 
accessible via the RTB and the Agency production equipment, and be supported by the 
Contractor, all in accordance with Section 11.7.2(b) above. These facilities, systems and 
services are considered to be in addition to, and not in lieu of, the maintenance, support and 
other obligations of the Contractor under the Contract. Additional compensation is provided in 
accordance with Section 3.1-76.3.13. 

j. Final “As built” Design Documents. Upon satisfactory completion of Phase 2 System 
Development, RFCS Release and Testing, all Phase 2 Final Design Review Documents shall be 
revised/updated with any changes that resulted from the development and testing process. Once 
NAC’d, revisions to a document will be submitted as a "Change Request" for written approval 
by the Agencies' Contract Administrator in accordance with RFCS change management process. 

Any documents that are unchanged as a result of Phase 2 activities shall be so noted, and the 
most recent version designated as the final as-built document. 

In any event, the Contractor shall provide a comprehensive list of the final “as-built” versions of 
all documentation, listing the document name, ERG reference number, most recent revision 
date, and revision number. 


k. Hardware Commissioning and Complete System Commissioning. 

1. The Contractor has been performing hardware commissioning on a device-by-device 
basis as it is installed at Agency facilities and on Agency vehicles. Completion of all 
such device commissioning, however, does not constitute "Completion of Complete 
System Commissioning." As agreed in Section 3 below, achieving said Milestone 
requires among other Contract obligations, that all RFCS devices that have been 
individually commissioned are fully operational. To the extent that such equipment has 
been disconnected from power after individual device commissioning, it will need to be 
"powered-up" and successfully loaded with the RFCS software that incorporates the 
applicable Phase 2 Revisions. 

The following activities shall be performed on days and at times agreed upon 
by the Parties in coordination with the training of an Agency's employees. 

(a) The Agencies will re-connect power to previously commissioned devices. 
The Contractor will provide field support at Agency facilities as necessary to 
assist the Agencies with any problems that arise during this activity. 

(b) The Contractor is responsible for ensuring that the final Phase 2 version of 
RFCS software is automatically downloaded as the devices are powered-up. 
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The Contractor will provide field support at Agency facilities as necessary to 
ensure this download is successful. 

(c) Because KCM's essential radio functionality is dependent on a successful 
download to the on-board equipment (OBE), the Contractor shall take the 
following additional actions to support KCM's re-connecting of power to the 
OBFTP and the downloading of the final Phase 2 RFCS software to KCM's 
OBE. Prior to commencing the above re-powering and downloading activities 
for the entire KCM fleet, the Contractor and KCM will conduct a pilot test of 
ten buses on a Sunday to identify and resolve issues. Thereafter, the Contractor 
will assign a knowledgeable person to be present at KCM facilities to 
troubleshoot and support the activity of reconnecting power and downloading 
the final RFCS software to the OBE. 

2. As provided in Section 6.1I-11.4.5(a), the Contractor shall submit a Plan for 
Complete System Commissioning to "demonstrate that all systems are fully operational 

prior to entering revenue service." As provided in Section 6.11-11.4.5(b), said Plan for 
Complete System Commissioning shall: 

...identify and describe all necessary tests to verify proper interfacing and 
installation of the equipment with other system facilities, including at a 
minimum: 

i. Schedule for system commissioning. 

ii. Commissioning test period. 

iii. Procedures for collecting and verifying data from each 
type of equipment. 

iv. Procedures for verifying the correct transfer of control 
commands to each type of equipment. 

v. Test reports content to be prepared. 

3. The Milestone for "Completion of Complete System Commissioning" shall be 
deemed satisfied and eligible to be NAC'd upon the Contractor demonstrating 
that the following requirements have been met: 

(a) all Phase 2 Revisions have been successfully completed and tested as 
provided above; 

(b) all RFCS devices have been individually commissioned and are fully 
operational and in-service except for any devices that are not operational 
or in-service due to a cause specified in Section 3.1-53.3; and 

(c) the Complete System Commissioning Test has been successfully 
completed and all requirements of 6.1II-11.4.5 have been satisfied. 
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6.11- 12 Training Requirements 

6.11- 12.1 General Requirements 

The Contractor shall develop and conduct programs to train personnel in all aspects 

related to the equipment, hardware, support and diagnostic equipment, and software 

provided under this Contract. The Contractor shall: 

(a) Provide personnel with information and skills needed to operate, maintain, 
and support the equipment. 

(b) Offer at a minimum the courses listed in Figure 11-12.1. 

(c) at the Agency’s request, provide Agency personnel training after system 
implementation through the duration of the Contract. The prices for such 
training shall be as specified in Contract Exhibit 9. 

(d) Develop a comprehensive training program covering all necessary 
management, service, operations and maintenance skills and procedures for 
Contractor personnel. The parameters, approach and materials for Contractor 
personnel training shall be subject to Contract Administrator approval. 

(e) Training Manuals shall reference and/or incorporate the content of the 
Operations and Maintenance Manuals where appropriate. 

12.1.1 Training Program Plans 

The Contractor shall develop and submit to the Contract Administrator for 
approval a Training Program Plan (CDRL 28) comprising two (2) parts - 
one addressing training courses designed for Agency personnel, the other 
addressing the Contractor’s training program for Contractor personnel. 

The plans are to be based upon criteria identified in this 
specification. Each plan shall, at a minimum, provide the following for 
each course: 

(a) Brief course description. 

(b) Expected performance objectives and how the expected objectives 
will be measured. 

(c) Outline for the course content. 

(d) Type or method(s) of presentation that will be used. 

(e) Resources required (equipment, classroom/shop space, supplies). 





(f) An estimated time schedule to train (based on the required number 
of hours and/or sessions of instruction) employees. 

(g) Intended audience and the maximum class size. 

6.11-12.2 Training Courses 

The training program shall offer separate courses to address the different disciplines 
and personnel needs within the Agency organizations. In addition to the courses 
identified in Figure 11-12.1, the Contractor may propose other courses. 

Figure 11-12.1 

Training Course Matrix & Time Table 


Training Course 

RFCS Overview 

System Operations 

Repair and Maintenance 

Data Management 

Customer Service and Marketing 

Train-the-Trainer 


12.2.1 RFCS Overview Course 

The RFCS Overview Course shall be designed to provide management, 
supervisory, and engineering personnel with an overview of the system, 
including a functional understanding of the equipment and software. The 
course shall cover the marketing and customer support responsibilities of 
the Contractor, the Agency interface with Contractor personnel, and the 
function of each device, including the interrelationships of the equipment 
with customers and Agency employees. 

Personnel attending RFC Overview training sessions will include 
management personnel, public relations personnel, engineers, and other 
administrative and revenue servicing /accounting personnel. 











12.2.2 Operations Course 


The Operations Course shall be designed to provide Agency and 
designated Contractor personnel with the functional understanding of all 
RFC system components. This course shall also convey an understanding 
of the interrelationships of the equipment with customers and provide 
equipment monitoring and cleaning maintenance instructions to Agency 
personnel. 

12.2.3 Repair and Maintenance Course 

The Repair and Maintenance Course shall be designed to provide Agency 
service personnel and maintenance technicians with the knowledge and 
skills required to perform Agency preventive and corrective maintenance 
of the RFC systems. At a minimum, the course shall cover the operating 
software, maintenance of special test equipment (portable and stationary) 
provided, and built-in tests features. 

This course shall also provide repair and maintenance personnel with the 
training necessary to de-install and install equipment maintained through 
the Maintenance Program; manage the related spares inventory at Agency 
facilities; and interface with DACS in the administration of the 
Maintenance Program. The course shall include Level 2 and 3 circuit 
board and component level maintenance training for devices or systems 
maintained by the Agencies, including the Radio Control Unit (RCU) 
described in Section 6.III-6.8.3. 

12.2.4 Data Management Course 

The Contractor shall develop and deliver a course to train Agency and 
Contractor personnel in the procedures required to interface with the 
Clearinghouse system. These include all the procedures required to 
support financial settlement, reconciliation and adjustments, to access 
financial and statistical data from various DACS, to manage the associated 
movement of funds, and to produce standard and custom reports. This 
course shall also provide to Agency personnel an descriptions and 
processes for Contractor-related operations, including the financial 
settlement, call handling, and data management processes. 

12.2.5 Customer Service and Marketing Course 

The Contractor shall develop and deliver a course to train Agency and 
Contractor personnel in the procedures for customer service and ongoing 
marketing activities. Among other topics, this course shall address 
Customer Service “counter training” for personnel interacting directly 
with the public. The Call Center and Walk-in Center training and 
materials shall include content on the use of the Cardholder Website. 



12.2.6 


Train the Trainer Course 


The Contractor shall provide a “Train the Trainer” course. This course 
shall be designed to train supervisory personnel at participating Agencies 
to deliver any of the proposed training courses (as applicable to that 
Agency) subsequent to the Contractor’s involvement. This class shall be 
sufficiently detailed and identify the resources and the number of 
instruction hours necessary to complete the program. 

6.11-12.3 Training Materials 

(a) The Contractor shall provide a list of training materials required for each 
course discussed in the Training Program Plan (CDRL 29). 

(b) The Contractor shall reflect all changes and revisions to the installed RFCS in 
all training materials, whether supplied to Agencies, or used in Contractor- 
conducted training courses. 

(c) At a minimum the following training materials shall be provided for each 
course: instructor guides, student workbooks, mock-ups, scale models, 
overhead transparencies and/or slides, and video-taped demonstrations. 

(d) All Instructor and student books shall be loose leaf bound, camera ready 
copies that are printed on 8V 2 x 11 inch paper, double sided. The Contractor 
shall also be responsible for providing instructor and student books in 
electronic form on CD ROM in the following formats: 

i. Text shall be provided in the latest version (current production version 
at deployment, as agreed to by the Contract Administrator) of Adobe 
Acrobat and Microsoft Word or approved commercially available 
word processing program. 

ii. Drawings shall be provided in .eps or .dxf file formats. 

iii. Graphics files shall be provided in TIFF, GIF and/or JPEG file 
formats. 

(e) If the Contractor identifies proprietary information contained in such 
documents that should not be available to the general public, then the 
Contractor is responsible for implementing the proper security measures for 
restricting access. Agency personnel and designated advisors or consultants 
shall have free access to such documentation. 

(f) All final materials required for training classes shall be delivered to the 
Agencies at least two weeks prior to the scheduled start date of the class. All 
training materials shall use English text and shall become the property of the 
Agencies. 



(g) The Contractor shall be responsible for updating training materials to reflect 
current RFCS parameters in the event that changes are made to the system or 
operational procedures. Such materials shall be updated and maintained by 
the Contractor throughout the life of the Contract. 

(h) At the end of the Contract, all such materials shall become property of the 
Agencies. 

12.3.1 Instructor Guides 

Instructor guides for all training classes identified in the Training Program 
Plan shall include: 

(a) Course agenda and objectives. 

(b) Resources and facilities required for the course. 

(c) Detailed lesson plans or outlined presentations and discussion 
guides. 

(d) Pre- and post training assignments. 

(e) Instructions for using any audio-visual support, mock-ups, and 
scale models. 

The Contractor shall provide one hundred (100) copies of instructor guides 
for each course to the Agencies. 

12.3.2 Student Workbooks 

The Contractor shall provide for each course in the Training Program Plan 
a student workbook. The student workbook shall contain all materials 
necessary to help the student understand the lessons being presented and 
serve as an on-the-job reference. The workbook shall include paper copies 
of all the transparencies, lecture outlines, lesson summaries, and other 
information that will help students understand the material and apply their 
knowledge in the field environment. The workbook shall also include 
step-by-step instructions for the operation of each device in the RFC 
system, and a trouble-shooting guide for Transit Operators. 

12.3.3 Mock-Ups and Scale Models 

The Contractor shall provide mock-ups and scale models to be used as 
instructional aids during the training courses. Mock-ups and scale models 
are to be constructed of secure, durable materials that will survive ten (10) 
years of use in a classroom environment. 



12.3.4 Overhead Transparencies 

Overhead transparencies (view-graphs) used in training shall be supplied 
along with camera-ready copy. Master copies of slides and other audio¬ 
visual materials shall be provided to allow for reproduction as necessary. 

12.3.5 Video Tapes and Interactive Computer Programs 

(a) Video tapes and interactive computer programs shall be provided, 
where applicable, as an instructional aid to the course 
material. These media shall also be available to permit Agency 
personnel to train, refresh, or update themselves at the Agency 
facilities. 

(b) Video tapes shall thoroughly cover the topic discussed. Video 
tapes shall be identified according to subject. A master list of 
video tapes, cross referenced to the instructor’s syllabus, shall be 
provided. Interactive computer programs shall be furnished on 
compact disk (CD ROM). 

(c) Instructional video tapes are to be of professional quality recorded 
on standard 1/2 inch US format VHS film. Protective cases shall 
be provided for all videos. All material must be supplied in either 
audio or video format including but not limited to close captioned 
for hearing impaired. 

6.11- 12.4 Classroom and Practical Training Space 

Training shall be conducted at Agency facilities or at a central location in Puget 
Sound Area to be agreed between Contractor and Agencies. All required training 
equipment such as slide projectors, videocassette recorders/players, monitors, 
computers, screens, easels and similar equipment shall be provided by Contractor. 

6.11- 12.5 Training Program Approval and Instructor Qualification 

The Contract Administrator shall have the rights to review, approve and accept all of 
the training materials and course work prior to the Contractor’s use in execution of 
training. The Contractor shall warrant that all instructors are fully qualified to present 
the course material. The Contract Administrator shall reserve the right to request 
replacement of instructors it deems to be unqualified or whose performance it deems 
unsatisfactory for any reason. 

6.11- 12.6 PHASE 2 TRAINING 


6.11-12.6.1 


All Phase 2 Manuals (CDRL 34, 35), Training Manuals (CDRL 29) and the 
Training Plan (CDRL 28) shall be revised to comply with the Contract requirements, the 



provisions of the Beta Readiness Waiver Agreement, and to reflect any Phase 2 
Revisions. Said documents shall be subject to Agency review and issuance of a NAC as 
provided in Contract Section 3.1-27.5 (Phase 2). 


6.11-12.6.2 


The revised Training Plan shall be delivered with the Overall RFCS Release Plan. 

6.11-12.6.3 

The revised Manuals and Training materials shall be delivered to the Agencies at such 
time as any related RFCS Release is released into the RTB and will be used by the 
Agencies in the user testing, unless the Parties agree in the NAC’s Overall RFCS Relase 
Plan that such Manuals and Training Materials may be delivered with a subsequent 
related RFCS Release into the RTB. 

6.IL12.6.4 

Whether before or after a NAC is issued for the Training Plan, Manuals and Training 
Materials, the Contractor shall modify said Deliverables as necessary to reflect results of user 
testing, correction of errors or inconsistencies, and to reflect further Phase 2 Revisions that arise 
to address issues identified. Once NAC’s, revisions to a document will be submitted as a 
“Change Request” for written approval by the Agencies’ Contract Administrator in accordance 
with RFCS change management process. 



